Signing and authentication methods for bit stream

Abstract

Provided in the embodiments of the present application are signing and authentication methods for a bit stream. The bit stream comprises: a group of data units, and an authentication identifier of each data unit among the group of data units. The signing method comprises: first, acquiring authentication data, wherein the authentication data comprises: signature data, an authentication identifier of each data unit among a group of data units, and digest data of each data unit among the group of data units, the signature data being obtained by means of performing signing on the basis of the digest data of each data unit among the group of data units; and then, adding the authentication data into a bit stream. In this way, each data unit may be independently authenticated at an authentication end; therefore, when some data units are lost (frames are lost), the other data units may also be authenticated. In addition, since the authentication identifiers are used to identify the data units, the one-to-one correspondence between the data units and the authentication data is ensured, thereby avoiding the problem of the data units not matching the authentication data due to the signing time being relatively long.

Description

Codestream signature and authentication method

[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office of China on November 28, 2023, with application number 202311614838.5 and application name “Signature and Authentication Method for Code Stream”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The embodiments of the present application relate to the field of media, and in particular to a method for signing and authenticating a code stream. Background Art

[0003] Many audio and video encoding and decoding scenarios (for example, surveillance, live broadcast, on-demand, etc.) have 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, the audio and video content needs to be signed.

[0004] However, the current tree-based signature technology for audio and video content has some defects: for example, if a single Network Abstract Layer (NAL) unit is wrong, or the order of the NAL units changes during transmission, the authentication of multiple NAL units involved in the authentication will fail. For another example, each NAL unit or NAL unit sequence cannot be authenticated separately. For another example, 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 makes the authentication very complicated and difficult to implement using existing technologies. For another example, the encoding rate is relatively fast, but the signing time is long, which will lead to the uncertainty of the position of the authentication data in the bitstream; or, if the authentication data of the previous frame of the NAL unit sequence is lost, it is impossible to match the authentication data with the corresponding NAL unit sequence that needs to be authenticated; and so on.

[0005] Summary of the Invention

[0006] In view of this, the present application provides a code stream signature and authentication method.

[0007] In a first aspect, an embodiment of the present application provides a method for signing a code stream, wherein the code stream includes: a group of data units and an authentication identifier for each data unit in the group of data units. The method includes: first, obtaining authentication data; wherein the authentication data includes: signature data, the authentication identifier for each data unit in the group of data units, and summary data of each data unit in the group of data units, and the signature data is obtained by signing based on the summary data of each data unit in the group of data units; then, adding the authentication data to the code stream.

[0008] 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 a group of data units.

[0009] In other words, this application independently summarizes each data unit and transmits the summary data of each data unit to the authentication end. This allows the authentication end to independently authenticate each data unit. Therefore, even if some data units are lost (frame loss), other data units can still be authenticated. In addition, because the data units are identified with authentication identifiers, a one-to-one correspondence between data units and authentication data is guaranteed, avoiding the problem of mismatch between data units and authentication data due to long signing times.

[0010] For the Scalable Video Coding (SVC) encoding of the Surveillance Video and Audio Coding (SVAC) standard, each data unit uses temporal_id to identify the temporal layer it is in. During decoding, some temporal layers or data units may not participate in decoding; in this application, since each data unit is independently summarized, during authentication, for data units participating in authentication, the corresponding summary data can be found in the authentication data, and data units not participating in authentication do not affect the authentication of other data units.

[0011] For the spatial domain SVC encoding of the SVAC standard, each data unit uses layer_id to identify the spatial domain layer it is in. During decoding, some spatial domain layers or data units may not participate in decoding; in this application, since each data unit has its own summary data, during authentication, for data units participating in authentication, the corresponding summary data can be found in the authentication data, and data units not participating in authentication will not affect the authentication of other data units.

[0012] For the video quality SVC encoding of the SVAC standard, during decoding, there may be certain quality levels or data units that do not participate in decoding. In this application, since each data unit has independent summary data, during authentication, for the data units participating in authentication, the corresponding summary data can be found in the authentication data, and the data units that do not participate in authentication will not affect the authentication of other data units.

[0013] In addition, for SVC coding, only one set of authentication data units needs to be transmitted to support authentication of the sub-bitstream extracted from the codestream.

[0014] In other words, the present application can also effectively solve the problem that the current SVC coding time domain SVC coding, spatial domain SVC coding, and video quality SVC coding require independent certification.

[0015] data unit

[0016] The basic syntax structure of the coded bit stream can be either a NAL unit or an access unit.

[0017] NAL unit

[0018] A syntax structure that contains an indication of the type of data that follows and the number of bytes it contains (located in the NAL header). The data appears in the form of a Raw Byte Sequence Payload (RBSP), which may also include interspersed security bytes.

[0019] access unit access unit

[0020] A set of NAL units that are related to each other according to specified rules and are consecutive in decoding order.

[0021] It should be noted that, from another perspective, a data unit may also include a coded image.

[0022] coded picture

[0023] The encoded representation of a frame of image.

[0024] It should be noted that this application does not group the data units, but uses "a group of data units" to describe them for the convenience of description.

[0025] Exemplarily, a group of data units may include n data units, all of which require authentication, where n is a positive integer. Accordingly, the authentication data may include n authentication identifiers and n summary data, with each of the n authentication identifiers corresponding one-to-one to the n data units, and each of the n summary data corresponding one-to-one to the n data units. Exemplarily, "a group of data units" may also be described as "n data units."

[0026] Exemplarily, the authentication identifier may also be referred to as an authentication serial number (eg, it may be represented by authentication_id).

[0027] Exemplarily, a plurality of summary data of a group of data units may constitute a summary data list; that is, the authentication data may include the summary data list.

[0028] Exemplarily, the authentication data may be Auth.

[0029] Exemplarily, the signature data may be signature.

[0030] Exemplarily, the summary data may also be referred to as authentication summary data.

[0031] For example, the code stream may be an audio compression code stream (or audio compression bit stream) or a video compression code stream (or video compression bit stream), and this application does not limit this. This application uses the example of signing and authenticating a video compression code stream for illustration.

[0032] bitstream

[0033] A binary data stream formed by encoding image / audio frames.

[0034] According to the first aspect, the method further comprises: calculating each data unit in a group of data units according to a digest algorithm to obtain digest data of each data unit in the group of data units. In this way, the digest data of each data unit can be quickly determined.

[0035] For example, data unit 1 in a group of data units is calculated according to the digest algorithm to obtain the digest data of data unit 1; data unit 2 in a group of data units is calculated according to the digest algorithm to obtain the digest data of data unit 2; ..., and so on.

[0036] Exemplarily, a hash calculation (Hash) may be performed on each data unit in a group of data units according to a digest algorithm to obtain digest data of each data unit in the group of data units.

[0037] It should be understood that this application does not limit the type of digest algorithm.

[0038] Exemplarily, the summary data may also be referred to as authentication summary data (such as authentication_hash).

[0039] According to the first aspect, or any implementation of the first aspect above, the method further includes: concatenating the summary data of each data unit in a group of data units to determine a summary of the concatenated summary data; and signing the summary data of the concatenated summary data using a private key to obtain signature data. In this way, the signature data can be quickly determined.

[0040] Exemplarily, the concatenation can be concatenation. For example, if 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. A hash calculation is performed on the concatenated digest data H1+H2+H3+H4+H5+...+Hn to obtain the summary data Hg of the concatenated digest data.

[0041] It should be understood that it is also possible to generate tree-top summary data and use a private key to sign the tree-top summary data to obtain signature data. This application does not limit the method of signing based on the summary data of the data unit.

[0042] Exemplarily, the private key may be Private Key.

[0043] According to the first aspect, or any implementation of the first aspect above, the method further includes: generating authentication data based on the signature data, the authentication identifier of each data unit in a group of data units, and the summary data of each data unit in a group of data units.

[0044] According to the first aspect, or any implementation of the first aspect above, adding the authentication data to the bitstream includes encoding the authentication data and adding the encoded authentication data to the bitstream, thereby reducing bitrate overhead.

[0045] Exemplarily, the authentication data may be encoded using Base64; then, the encoded authentication data is packaged into a NAL unit of authentication data in the code stream.

[0046] According to the first aspect, or any implementation of the first aspect above, each data unit in a group of data units includes one or more network abstraction layer NAL units.

[0047] Exemplarily, when the data unit is a NAL unit, a group of data units may include multiple NAL units, each with a different authentication identifier. When the data unit is multiple NAL units, a group of data units may include multiple access units, each with a different authentication identifier, and each access unit may contain multiple NAL units with the same authentication identifier.

[0048] According to the first aspect, or any implementation of the first aspect above, 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 continuous. That is, one data unit is an access unit

[0049] According to the first aspect, or any implementation of the first aspect above, each data unit in a group of data units includes a coded image.

[0050] According to the first aspect, or any implementation of the first aspect above, each NAL unit includes the authentication identifier of the data unit to which it belongs, so that the authentication end can easily obtain the one-to-one correspondence between the NAL unit and the authentication identifier.

[0051] Specifically, the NAL header of each NAL unit may include the authentication identifier of the data unit to which it belongs.

[0052] For example, compared with the prior art, the NAL unit of the present application adds an authentication identifier authentication_id.

[0053] According to the first aspect, or any implementation of the first aspect above, the authentication identifier of each data unit in a group of data units in a code stream is located before the group of data units. In this way, the authenticating end can receive the authentication identifier of each data unit in the group of data units before receiving the group of data units. This ensures that the authenticating end marks each data unit in the received group of data units based on the authentication identifier of each data unit in the group of data units, determines the authentication identifier of each data unit, and ensures the correspondence between the data unit and the authentication data.

[0054] According to the first aspect, or any implementation of the first aspect above, the code stream further includes a security parameter set, and the security parameter set includes an authentication identifier of each data unit in a group of data units.

[0055] Illustratively, the security parameter set precedes a group of data units.

[0056] For example, compared with the prior art, the security parameter set of the present application adds: authentication_id (also known as authentication identifier).

[0057] In one possible approach, the security parameter set in the codestream is represented in the form of an RBSP. Therefore, the codestream also includes a security parameter set, and the security parameter set includes an authentication identifier for each data unit in a group of data units. This can be written as: the codestream also includes a security parameter set RBSP, and the security parameter set RBSP includes an authentication identifier for each data unit in a group of data units.

[0058] According to the first aspect, or any implementation of the first aspect above, the code stream further includes extended information, and the extended information includes an authentication identifier of each data unit in a group of data units.

[0059] Exemplarily, the extension information is located before a group of data units.

[0060] For example, the CEI extended information of the present application is newly added with: authentication_id (also known as authentication identifier).

[0061] Optionally, hash_type (hash type, indicating the algorithm used for authentication), signature_type (digital signature type, indicating the algorithm for digitally signing the summary data of the image (or data unit)) and authentication_flag (indicating whether the video data (or data unit) following the extended data is authenticated) may be added to the CEI extended information of this application.

[0062] According to the first aspect, or any implementation of the first aspect above, the code stream further includes a first identifier, and the first identifier indicates an authentication mode adopted by a group of data units.

[0063] For example, the first identifier may be authenticate_mode.

[0064] If authenticate_mode is 0, it indicates that each data unit is independently authenticated by digest data;

[0065] If authenticate_mode is 1, it indicates the tree digest data authentication mode.

[0066] According to the first aspect, or any implementation of the first aspect above, the code stream further includes a security parameter set, and the security parameter set includes the first identifier.

[0067] For example, compared with the prior art, the security parameter set of the present application further adds: authenticate_mode (which may be referred to as the first identifier).

[0068] According to the first aspect, or any implementation of the first aspect above, the code stream 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 time domain layer, and the value of the second identifier is 0.

[0069] Since in the time domain SVC coding scenario of the SVAC standard, the time domain base layer (i.e., the data unit with the second identifier being 0) needs to be parsed, in order to ensure that authentication data can be obtained during the authentication process regardless of whether the time domain enhancement layer is parsed, the value of the second identifier in the NAL unit of the authentication data can be set to 0.

[0070] In one possible manner, the authentication data in the code stream is represented in the form of RBSP. Therefore, the code stream also includes a NAL unit of the authentication data, and the NAL unit of the authentication data includes a second identifier. This can be written as: the code stream also includes an authentication unit of the authentication data RBSP, and the NAL unit of the authentication data RBSP includes the second identifier.

[0071] Exemplarily, the second identifier may be temporal_id.

[0072] For example, compared with the prior art, authentication data is newly added with authentication_id (authentication identifier) ​​and authentication_hash (digest data).

[0073] According to the first aspect, or any implementation of the first aspect above, the code stream also 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.

[0074] Since the spatial base layer / quality coding base layer (i.e., the data unit with the third identifier being 0) needs to be parsed in the spatial SVC coding or quality SVC coding scenarios of the SVAC standard, in order to ensure that authentication data can be obtained during the authentication process regardless of whether the spatial enhancement layer / quality coding enhancement layer is parsed, the value of the third identifier in the NAL unit of the authentication data can be set to 0.

[0075] Exemplarily, the third identifier may be layer_id.

[0076] It should be noted that the authentication data in the first aspect and any implementation of the first aspect may also include a public key corresponding to the private key. Exemplarily, the public key is a public key, which can be used to verify the signature data. It should be understood that the public key corresponding to the private key may also be transmitted via other means, such as being built into the authentication terminal, being included in an authentication certificate, and being transmitted to the authentication terminal, etc., and this application does not impose any restrictions on this.

[0077] It should be noted that the first aspect and any implementation method of the first aspect can be executed by the encoder in the signature end, or by the signature module in the signature end, or by the encoder and authentication module in the signature end in collaboration. This application does not impose any restrictions on this.

[0078] In a second aspect, an embodiment of the present application provides a code stream, which includes: a group of data units, authentication data, and an authentication identifier of each data unit in the group of data units; wherein the authentication data includes: signature data, an authentication identifier of each data unit in the group of data units, and summary data of each data unit in the group of data units, and the signature data is obtained by signing based on the summary data of each data unit in the group of data units.

[0079] According to the second aspect, the authentication identifier of each data unit in a group of data units is located before the group of data units.

[0080] According to the second aspect, or any implementation of the second aspect above, the code stream further includes a security parameter set, and the security parameter set includes an authentication identifier of each data unit in a group of data units.

[0081] According to the second aspect, or any implementation of the second aspect above, the code stream further includes extended information, and the extended information includes an authentication identifier of each data unit in a group of data units.

[0082] According to the second aspect, or any implementation of the second aspect above, each data unit in a group of data units includes one or more network abstraction layer NAL units.

[0083] According to the second aspect, or any implementation of the second aspect above, 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 continuous. That is, one data unit is an access unit

[0084] According to the second aspect, or any implementation of the second aspect, each data unit in a group of data units includes a coded image.

[0085] According to the second aspect, or any implementation of the second aspect above, each NAL unit includes an authentication identifier of the data unit to which it belongs.

[0086] According to the second aspect, or any implementation of the second aspect above, the code stream further includes a first identifier, and the first identifier indicates an authentication mode adopted by a group of data units.

[0087] According to the second aspect, or any implementation of the second aspect above, the code stream further includes a security parameter set, and the security parameter set includes the first identifier.

[0088] According to the second aspect, or any implementation of the second aspect above, the code stream 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 time domain layer, and the value of the second identifier is 0.

[0089] According to the second aspect, or any implementation of the above second aspect, the code stream also 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.

[0090] According to the second aspect, or any implementation of the second aspect above, the code stream 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 amount of summary data included in the authentication data.

[0091] Exemplarily, the fourth identifier may be authentication_hash_number_minus1, which is also a new syntax element added to the NAL unit of the authentication data of the present application.

[0092] The second aspect and any implementation of the second aspect correspond to the first aspect and any implementation of the first aspect, respectively. The technical effects corresponding to the second aspect and any implementation of the second aspect can be referred to the technical effects corresponding to the first aspect and any implementation of the first aspect, and will not be repeated here.

[0093] In a third aspect, an embodiment of the present application provides a method for authenticating a code stream, the method comprising: first, obtaining a first authentication identifier of each data unit in a group of data units from the code stream; then, determining first summary data of each data unit in the group of data units; thereafter, obtaining authentication data from the code stream, the authentication data comprising: signature data, a second authentication identifier of each data unit in the group of data units, and second summary data of each data unit in the group of data units, the signature data being obtained by signing based on the second summary data of each data unit in the group of data units; subsequently, when the signature data is successfully verified, storing the authentication data in an authentication data list; then, searching the authentication data list for authentication data that matches multiple first authentication identifiers of a group of data units; wherein the matched authentication data comprises multiple second authentication identifiers that are respectively identical to the multiple first authentication identifiers of the group of data units; and verifying the multiple first summary data in the group of data units based on the multiple second summary data in the matched authentication data.

[0094] It should be noted that the second authentication identifier and the first authentication identifier are used to distinguish authentication identifiers in the authentication data from authentication identifiers elsewhere in the code stream. The first summary data and the second summary data are used to distinguish summary data calculated by the authentication terminal from summary data in the authentication data.

[0095] According to a third aspect, determining first summary data of each data unit in a group of data units includes: calculating each data unit in the group of data units according to a summary algorithm to obtain the first summary data of each data unit in the group of data units.

[0096] In one possible approach, when hash_type is parsed from the security parameter set RBSP of the code stream, each data unit in a group of data units can be calculated according to the authentication algorithm (i.e., digest algorithm) indicated by hash_type to obtain the first digest data of each data unit in the group of data units.

[0097] For example, a hash calculation may be performed on each data unit in a group of data units 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 group of data units.

[0098] In one possible approach, when hash_type is not parsed from the security parameter set RBSP of the codestream, each data unit in a group of data units may be calculated according to a pre-agreed digest algorithm to obtain digest data of each data unit in the group of data units.

[0099] According to the third aspect, or any implementation of the third aspect above, the method also includes: obtaining a public key; connecting the second summary data of each data unit in a group of data units to determine the summary data of the connected second summary data; and verifying the signature data based on the public key, the summary data of the connected second summary data and the signature algorithm.

[0100] Exemplarily, when the authentication data generated in the signing end also includes a public key corresponding to the private key used for signing, the public key can also be parsed from the authentication data RBSP.

[0101] In one possible approach, when the signature_type is parsed from the codestream security parameter set RBSP, the signature algorithm may be determined according to the signature algorithm indicated by the signature_type.

[0102] One possible approach is to find the signature algorithm in the authentication certificate indicated by camera_idc when the camera_idc is obtained from the security parameter set RBSP of the codestream.

[0103] In one possible approach, the public key may be parsed from the authentication data RBSP of the code stream.

[0104] In one possible approach, a public key pre-built into the authentication terminal 220 may be obtained.

[0105] In one possible approach, the signature algorithm may be determined according to a pre-agreed signature algorithm.

[0106] According to the third aspect, or any implementation of the third aspect above, the method also includes: obtaining a first identifier from the code stream, the first identifier indicating the authentication mode adopted by a group of data units; when the value of the first identifier is a first preset value, executing the step of determining the first summary data of each data unit in the group of data units.

[0107] According to the third aspect, or any implementation of the third aspect above, the method further includes: obtaining a fourth identifier from the code stream, and determining a value n based on the fourth identifier; wherein a group of data units includes n data units, and n is a positive integer; and obtaining second summary data of each of the n data units from the code stream.

[0108] According to the third aspect, or any implementation of the third aspect above, each data unit in a group of data units includes one or more network abstraction layer NAL units.

[0109] According to the third aspect, or any implementation of the 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 continuous.

[0110] According to the third aspect, or any implementation of the third aspect above, each data unit in a group of data units includes a coded image.

[0111] According to the third aspect, or any implementation of the third aspect above, multiple first summary data in a group of data units are verified based on multiple second summary data in the matching authentication data, including: for a first data unit in the group of data units: if second summary data identical to the first summary data of the first data unit is found in the multiple second summary data in the matching 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 has failed.

[0112] It should be noted that the third aspect and any implementation method of the third aspect can be executed by the decoder in the authentication end, or by the authentication module in the authentication end, or by the decoder and authentication module in the authentication end in collaboration. This application does not impose any restrictions on this.

[0113] The third aspect and any implementation of the third aspect correspond to the first aspect and any implementation of the first aspect, respectively. The technical effects corresponding to the third aspect and any implementation of the third aspect can be referred to the technical effects corresponding to the first aspect and any implementation of the first aspect, and will not be repeated here.

[0114] In a fourth aspect, an embodiment of the present application provides a signature device for a code stream, wherein the code stream includes: a group of data units and an authentication identifier for each data unit in the group of data units, and the signature device for the code stream includes:

[0115] A first authentication data acquisition module is configured to acquire authentication data; wherein the authentication data includes signature data, an authentication identifier of each data unit in a set of data units, and summary data of each data unit in the set of data units, wherein the signature data is obtained by signing the summary data of each data unit in the set of data units;

[0116] Add module to add authentication data to the code stream.

[0117] Illustratively, the above-mentioned code stream signature device can be used to execute the signature method in the first aspect or any possible implementation of the first aspect.

[0118] The fourth aspect and any implementation of the fourth aspect correspond to the first aspect and any implementation of the first aspect, respectively. The technical effects corresponding to the fourth aspect and any implementation of the fourth aspect can be referred to the technical effects corresponding to the first aspect and any implementation of the first aspect, and will not be repeated here.

[0119] In a fifth aspect, an embodiment of the present application provides a device for authenticating a code stream, the device comprising:

[0120] An authentication identifier acquisition module, configured to acquire a first authentication identifier of each data unit in a group of data units from a code stream;

[0121] a summary data determination module, configured to determine first summary data of each data unit in a group of data units;

[0122] a second authentication data acquisition module, configured to acquire authentication data from the code stream, the authentication data including signature data, a second authentication identifier for each data unit in a group of data units, and second digest data for each data unit in the group of data units, the signature data being obtained by signing the second digest data for each data unit in the group of data units;

[0123] An authentication data storage module is used to store the authentication data in an authentication data list when the signature data is successfully verified;

[0124] an authentication data search module, configured to search, from an authentication data list, for authentication data that matches a plurality of first authentication identifiers of a group of data units; wherein the matching authentication data includes a plurality of second authentication identifiers that are respectively identical to the plurality of first authentication identifiers of the group of data units;

[0125] The verification module is configured to verify the plurality of first summary data in a group of data units according to the plurality of second summary data in the matched authentication data.

[0126] Illustratively, the above-mentioned code stream authentication device can be used to execute the authentication method in the third aspect or any possible implementation manner of the third aspect.

[0127] The fifth aspect and any implementation of the fifth aspect correspond to the third aspect and any implementation of the third aspect, respectively. The technical effects corresponding to the fifth aspect and any implementation of the fifth aspect can be referred to the technical effects corresponding to the third aspect and any implementation of the third aspect, and will not be repeated here.

[0128] In a sixth aspect, an embodiment of the present application provides an electronic device, comprising: a memory and a processor, the memory being coupled to the processor; the memory storing program instructions, which, when executed by the processor, enables the electronic device to execute the code stream signing method of the first aspect or any possible implementation of the first aspect.

[0129] The sixth aspect and any implementation of the sixth aspect correspond to the first aspect and any implementation of the first aspect, respectively. The technical effects corresponding to the sixth aspect and any implementation of the sixth aspect can be referred to the technical effects corresponding to the first aspect and any implementation of the first aspect, and will not be repeated here.

[0130] In the seventh aspect, an embodiment of the present application provides an electronic device, comprising: a memory and a processor, the memory being coupled to the processor; the memory storing program instructions, which, when executed by the processor, enables the electronic device to execute the code stream authentication method in the third aspect or any possible implementation of the third aspect.

[0131] The seventh aspect and any implementation of the seventh aspect correspond to the third aspect and any implementation of the third aspect, respectively. The technical effects corresponding to the seventh aspect and any implementation of the seventh aspect can be referred to the technical effects corresponding to the third aspect and any implementation of the third aspect, and will not be repeated here.

[0132] In an eighth aspect, an embodiment of the present application provides a chip comprising 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 code stream signing method in the first aspect or any possible implementation of the first aspect are executed.

[0133] The eighth aspect and any implementation of the eighth aspect correspond to the first aspect and any implementation of the first aspect, respectively. The technical effects corresponding to the eighth aspect and any implementation of the eighth aspect can be referred to the technical effects corresponding to the first aspect and any implementation of the first aspect, and will not be repeated here.

[0134] In the ninth aspect, an embodiment of the present application provides a chip comprising 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 code stream authentication method in the third aspect or any possible implementation of the third aspect are executed.

[0135] The ninth aspect and any implementation of the ninth aspect correspond to the third aspect and any implementation of the third aspect, respectively. The technical effects corresponding to the ninth aspect and any implementation of the ninth aspect can be referred to the technical effects corresponding to the third aspect and any implementation of the third aspect, and will not be repeated here.

[0136] In a tenth aspect, an embodiment of the present application provides a computer-readable storage medium, which stores a computer program. When the computer program runs on a computer or a processor, the computer or the processor executes the code stream signing method in the first aspect or any possible implementation of the first aspect.

[0137] The tenth aspect and any implementation of the tenth aspect correspond to the first aspect and any implementation of the first aspect, respectively. The technical effects corresponding to the tenth aspect and any implementation of the tenth aspect can be referred to the technical effects corresponding to the first aspect and any implementation of the first aspect, and will not be repeated here.

[0138] In the eleventh aspect, an embodiment of the present application provides a computer-readable storage medium, which stores a computer program. When the computer program runs on a computer or processor, it enables the computer or processor to execute the code stream authentication method in the third aspect or any possible implementation of the third aspect.

[0139] The eleventh aspect and any implementation of the eleventh aspect correspond to the third aspect and any implementation of the third aspect, respectively. The technical effects corresponding to the eleventh aspect and any implementation of the eleventh aspect can be referred to the technical effects corresponding to the third aspect and any implementation of the third aspect, and will not be repeated here.

[0140] In a twelfth aspect, an embodiment of the present application provides a computer program product, which includes computer instructions. When the computer instructions are executed by a computer or a processor, the computer or the processor executes the code stream signing method in the first aspect or any possible implementation of the first aspect.

[0141] The twelfth aspect and any implementation of the twelfth aspect respectively correspond to the first aspect and any implementation of the first aspect. The technical effects corresponding to the twelfth aspect and any implementation of the twelfth aspect can be referred to the technical effects corresponding to the above-mentioned first aspect and any implementation of the first aspect, and will not be repeated here.

[0142] In a thirteenth aspect, an embodiment of the present application provides a computer program product, which includes computer instructions. When the computer instructions are executed by a computer or a processor, the computer or the processor executes the code stream authentication method in the third aspect or any possible implementation of the third aspect.

[0143] The thirteenth aspect and any implementation of the thirteenth aspect correspond to the third aspect and any implementation of the third aspect, respectively. The technical effects corresponding to the thirteenth aspect and any implementation of the thirteenth aspect can be referred to the technical effects corresponding to the third aspect and any implementation of the third aspect, and will not be repeated here.

[0144] In a fourteenth aspect, an embodiment of the present application provides a computer-readable storage medium, which stores a code stream in the second aspect or any possible implementation of the second aspect.

[0145] The fourteenth aspect and any implementation of the fourteenth aspect correspond to the second aspect and any implementation of the second aspect, respectively. The technical effects corresponding to the fourteenth aspect and any implementation of the fourteenth aspect can be referred to the technical effects corresponding to the above-mentioned second aspect and any implementation of the second aspect, and will not be repeated here.

[0146] In a fifteenth aspect, an embodiment of the present application provides a device for storing a code stream, the device comprising: a receiver and at least one storage medium, the receiver being configured to receive the code stream in the second aspect or any possible implementation of the second aspect; and the at least one storage medium being configured to store the code stream.

[0147] The fifteenth aspect and any implementation of the fifteenth aspect correspond to the second aspect and any implementation of the second aspect, respectively. The technical effects corresponding to the fifteenth aspect and any implementation of the fifteenth aspect can be referred to the technical effects corresponding to the above-mentioned second aspect and any implementation of the second aspect, and will not be repeated here.

[0148] In the sixteenth aspect, an embodiment of the present application provides a device for transmitting a code stream, the device comprising: a transmitter and at least one storage medium, the at least one storage medium being used to store the code stream in the second aspect or any possible implementation of the second aspect; the transmitter being used to obtain the code stream from the storage medium and send the code stream to the end-side device through the transmission medium.

[0149] The sixteenth aspect and any implementation of the sixteenth aspect correspond to the second aspect and any implementation of the second aspect, respectively. The technical effects corresponding to the sixteenth aspect and any implementation of the sixteenth aspect can be referred to the technical effects corresponding to the above-mentioned second aspect and any implementation of the second aspect, and will not be repeated here.

[0150] In aspect 17, an embodiment of the present application provides a system for distributing code streams, the system comprising: at least one storage medium for storing at least one code stream in the second aspect or any possible implementation of the second aspect, a streaming media device for obtaining a target code stream from the at least one storage medium and sending the target code stream to an end-side device, wherein the streaming media device comprises a content server or a content distribution server.

[0151] The seventeenth aspect and any implementation of the seventeenth aspect correspond to the second aspect and any implementation of the second aspect, respectively. The technical effects corresponding to the seventeenth aspect and any implementation of the seventeenth aspect can be referred to the technical effects corresponding to the above-mentioned second aspect and any implementation of the second aspect, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0152] FIG1 is a schematic diagram of an exemplary application scenario;

[0153] FIG2 is a schematic diagram of an exemplary authentication and signature system 200;

[0154] FIG3 is a schematic diagram illustrating an exemplary signing process 300;

[0155] FIG4 is a schematic diagram illustrating an exemplary authentication process 400;

[0156] FIG5A is a schematic diagram illustrating an exemplary signing process 500;

[0157] FIG5B is a schematic diagram illustrating an exemplary signing process;

[0158] FIG6A is a schematic diagram illustrating an exemplary authentication process;

[0159] FIG6B is a schematic diagram illustrating an exemplary authentication process 600;

[0160] FIG7 is a schematic diagram illustrating an exemplary signing process 700;

[0161] FIG8A is a schematic diagram illustrating an exemplary authentication process;

[0162] FIG8B is a schematic diagram illustrating an exemplary authentication process 600;

[0163] FIG9 is a schematic diagram illustrating an exemplary signing process 900;

[0164] FIG10A is a schematic diagram illustrating an exemplary authentication process;

[0165] FIG10B is a schematic diagram illustrating an exemplary authentication process 1000;

[0166] FIG11 is a schematic diagram of an exemplary code stream signature device;

[0167] FIG12 is a schematic diagram illustrating an exemplary code stream authentication device;

[0168] FIG13 is a schematic structural diagram of an exemplary device. DETAILED DESCRIPTION

[0169] The following will be combined with the drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0170] The term "and / or" in this article is merely a description of the association relationship between associated objects, indicating that three relationships may exist. For example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone.

[0171] In the description and claims of the embodiments of this application, the terms "first" and "second" are used to distinguish different objects, rather than to describe a specific order of objects. For example, the terms "first target object" and "second target object" are used to distinguish different objects, rather than to describe a specific order of objects.

[0172] In the embodiments of this application, words such as "exemplarily" or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplarily" or "for example" in the embodiments of this application should not be interpreted as being preferred or advantageous over other embodiments or designs. Rather, the use of words such as "exemplarily" or "for example" is intended to present the relevant concepts in a concrete manner.

[0173] In the description of the embodiments of this application, unless otherwise specified, "multiple" means two or more. For example, "multiple processing units" means two or more processing units; "multiple systems" means two or more systems.

[0174] For example, the code stream signature and authentication method involved in this application can be applied to the signing and authentication of any one of an audio compression code stream (or audio compression bit stream) or a video compression code stream (or video compression bit stream), and this application does not limit this. This application uses the signing and authentication of a video compression code stream as an example for explanation.

[0175] bitstream

[0176] A binary data stream formed by encoding image / audio frames.

[0177] Figure 1 is a schematic diagram of exemplary application scenarios, showing a monitoring scenario, a live broadcast scenario, and a video-on-demand scenario.

[0178] Referring to Figure 1 , in an exemplary surveillance scenario, camera 11 can sign a surveillance video stream, obtaining a signed surveillance video stream 101. Signed surveillance video stream 101 is then sent to laptop computer 13 via network 12. Laptop computer 13 can then authenticate signed surveillance video stream 101, obtain and display an authentication result 105, and play surveillance video 104.

[0179] 1 , illustratively, in a live broadcast scenario, mobile phone 14 can sign a live video stream to obtain a signed live video stream 102. Then, signed live video stream 102 is sent to mobile phone 15 via network 12. Mobile phone 15 can then authenticate signed live video stream 102, obtain and display an authentication result 107, and play live video 106.

[0180] 1 , in an exemplary on-demand scenario, a personal computer 16 can sign an on-demand video stream to obtain a signed on-demand video stream 103. The signed on-demand video stream 103 is then sent to a mobile phone 17 via a network 12. The mobile phone 17 can then authenticate the signed on-demand video stream 103, obtain and display an authentication result 109, and play the on-demand video 108.

[0181] It should be understood that the present application can also be used in other audio and video encoding and decoding scenarios, such as digital content trusted scenarios, etc., and the present application does not limit this.

[0182] Fig. 2 is a schematic diagram of an exemplary authentication and signature system 200. Fig. 2 illustrates the authentication and signature process in Fig. 1 .

[0183] 2 , illustratively, the authentication and signature system 200 may include a signing end 210 and an authentication end 220 .

[0184] For example, the signing end 210 may be the camera 11, mobile phone 14 and personal computer 16 in FIG1 , and the authentication end 220 may be the laptop computer 13, mobile phone 15 and mobile phone 17 in FIG1 .

[0185] It should be understood that the same terminal device can serve as both the signing end 210 and the authentication end 220, and this application does not impose any restrictions on this.

[0186] 2 , illustratively, after acquiring the video data 201 , the signing end 210 may perform video encoding 21 on the video data 201 to obtain a code stream 202 ; and perform video signature 22 on the code stream 202 to obtain a signed code stream 203 .

[0187] For example, the video data 201 may be a surveillance video captured by the camera 11 in FIG. 1 , a live video recorded by the mobile phone 14 , or a video on demand produced by the personal computer 16 .

[0188] For example, the signed code stream 203 may be the signed surveillance video code stream 101, the signed live video code stream 102, or the signed on-demand video code stream 103 in FIG. 1 .

[0189] It should be noted that the video encoding 21 and video signing 22 operations can be performed in parallel.

[0190] It should be noted that, in one possible embodiment, the signing end 210 may include an encoder, which performs video encoding 21 and video signing 22. In another possible embodiment, the signing end 210 may include an encoder and a signature module, which performs video encoding 21 and video signing 22. In another possible embodiment, the signing end 210 may include a signature module, which performs video encoding 21 and video signing 22.

[0191] Afterwards, the signing end 210 may send the signed code stream 203 to the authenticating end 220 .

[0192] 2 , illustratively, after receiving the signed code stream 203 , the authentication end 220 may perform video authentication 23 on the signed code stream 203 to obtain an authentication result 205 ; and may perform video decoding 24 on the code stream 202 in the signed code stream 203 to obtain decoded video data 204 .

[0193] For example, the decoded video data 204 may be the surveillance video 104, the live video 106, or the on-demand video 108 in FIG. 1 .

[0194] For example, the authentication result 205 may be the authentication result 105, the authentication result 107, or the authentication result 109 in FIG. 1 .

[0195] It should be noted that the video authentication 23 and the video decoding 24 can be performed in parallel.

[0196] It should be noted that, in one possible embodiment, the authentication end 220 may include a decoder, and the decoder performs video decoding 24 and video authentication 23. In another possible embodiment, the authentication end 220 may include a decoder and an authentication module, and the decoder performs video decoding 24 and the authentication module performs video authentication 23. In another possible embodiment, the authentication end 220 may include an authentication module, and the authentication module performs video decoding 24 and video authentication 23.

[0197] It should be noted that when the signing end 210 performs lossless encoding, the video data and the decoded video data are the same; when the signing end 210 performs lossy encoding, there are differences between the video data and the decoded video data.

[0198] It should be noted that the encoder, decoder and authentication module can be implemented by software or hardware, and this application does not impose any restrictions on this.

[0199] FIG3 is a schematic diagram illustrating an exemplary signing process 300 , wherein the process 300 may be implemented by the signing terminal 210 .

[0200] S301, obtain authentication data; wherein the authentication data includes: signature data, authentication identifier of each data unit in a group of data units and summary data of each data unit in a group of data units, and the signature data is obtained by signing the summary data of each data unit in a group of data units.

[0201] For example, when authentication is required, the number n of data units requiring authentication is determined, and an authentication identifier for each of the n data units is generated; then, the authentication identifier for each data unit in the group of data units is added to the codestream, where n is a positive integer.

[0202] data unit

[0203] The basic syntax structure of the coded bit stream can be either a NAL unit or an access unit.

[0204] NAL unit

[0205] A syntax structure that contains an indication of the type of data that follows and the number of bytes it contains (located in the NAL header). The data appears in the form of a Raw Byte Sequence Payload (RBSP), which may also include interspersed security bytes.

[0206] access unit access unit

[0207] A set of NAL units that are related to each other according to specified rules and are consecutive in decoding order.

[0208] It should be noted that, from another perspective, a data unit may also include a coded image.

[0209] coded picture

[0210] The encoded representation of a frame of image.

[0211] Referring to Figure 3 , illustratively, the n data units in a code stream that require authentication are: data unit 1, data unit 2, ..., data unit n. These n data units that require authentication can be referred to as a group of data units. All subsequent references to a group of data units refer to data units that require authentication.

[0212] It should be noted that this application does not group the data units, but uses "a group of data units" to describe them for the convenience of description.

[0213] 3 , illustratively, the authentication identifiers in the code stream are: authentication identifier 1, authentication identifier 2, . . . , authentication identifier n.

[0214] It should be noted that the n authentication identifiers correspond one-to-one to 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 n authentication identifiers can indicate the authentication data used by the group of data units.

[0215] 3 , illustratively, a digest data can be independently calculated for each data unit in a group of data units, thereby obtaining the digest data (also referred to as authentication digest data) for each data unit in the group of data units. The n digest data may include: digest data 1, digest data 2, ..., digest data n; wherein the n digest data correspond one-to-one to 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.

[0216] Exemplarily, a signature may be performed based on the summary data of each data unit in a group of data units to obtain signature data (signature).

[0217] For example, authentication data (Auth) can be generated based on 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. In this way, the authentication data can be {authentication sequence number 1, authentication sequence number 2, ..., authentication sequence number n, digest data 1, digest data 2, ..., digest data n, signature}.

[0218] Optionally, the summary data of each data unit in a group of data units in the authentication data may constitute a summary data list {summary data 1, summary data 2, . . . , summary data n}.

[0219] S302: Add authentication data to the code stream.

[0220] Illustratively, after the authentication data is obtained, the authentication data may be added to the code stream to obtain a signed code stream, that is, the signed code stream 203 in FIG. 2 .

[0221] It should be noted that S301~S302 can be executed by the encoder in the signature end 210, or by the signature module in the signature end 210, or by the encoder and authentication module in the signature end 210 executed collaboratively (the encoder executes S302, and the authentication module executes S301). This application does not impose any restrictions on this.

[0222] FIG4 is a schematic diagram illustrating an exemplary authentication process 400 , wherein the process 400 may be implemented by the authentication terminal 220 , and the process 400 corresponds to the process 300 .

[0223] S401: Obtain a first authentication identifier of each data unit in a group of data units from a code stream.

[0224] 4 , illustratively, a code stream may include a data unit, an authentication identifier, and authentication data. To distinguish an authentication identifier in the authentication data from an authentication identifier elsewhere in the code stream, the authentication identifier elsewhere in the code stream may be referred to as a first authentication identifier, and the authentication identifier in the authentication data may be referred to as a second authentication identifier.

[0225] For example, the code stream can be parsed to read the first authentication identifier of the data unit requiring authentication from the code stream. The first authentication identifier may include authentication identifier 11, authentication identifier 12, ..., authentication identifier 1n. In this way, n data units can be determined to be data units requiring authentication. These n data units are respectively: data unit 1, data unit 2, ..., data unit n.

[0226] Exemplarily, n first authentication identifiers correspond one-to-one to 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.

[0227] S402: Determine first summary data of each data unit in a group of data units.

[0228] For example, n data units requiring authentication (i.e., a group of data units requiring authentication) can be read from the code stream. Next, a digest data is independently calculated for each data unit in the group of data units, thereby obtaining the digest data for each data unit in the group of data units. To distinguish the digest data calculated in S402 from the digest data included in the authentication data, the digest data calculated in S402 can be referred to as first digest data, and the digest data included in the authentication data can be referred to as second digest data.

[0229] 4 , illustratively, the n first summary data are: summary data 11 , summary data 12 , . . . , summary data 1n.

[0230] Exemplarily, the n first summary data correspond to the n data units in a one-to-one manner. For example, summary data 11 corresponds to data unit 1, summary data 12 corresponds to data unit 2, ..., summary data 1n corresponds to data unit n.

[0231] S403, obtaining authentication data from the code stream, the authentication data including: signature data, a second authentication identifier of each data unit in a group of data units, and second summary data of each data unit in a group of data units, the signature data being obtained by signing the second summary data of each data unit in the group of data units.

[0232] For example, the code stream can be parsed to read authentication data from the code stream, where 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).

[0233] Exemplarily, n pieces of second summary data may constitute a summary data list {summary data 21, summary data 22, . . . , summary data 2n}.

[0234] Exemplarily, the n second summary data correspond to the n data units in a one-to-one correspondence. For example, summary data 21 corresponds to data unit 1, summary data 22 corresponds to data unit 2, ..., summary data 2n corresponds to data unit n.

[0235] Exemplarily, the n second authentication identifiers correspond to the n data units in a one-to-one correspondence. For example, authentication identifier 21 corresponds to data unit 1, authentication identifier 22 corresponds to data unit 2, ..., authentication identifier 2n corresponds to data unit n.

[0236] S404: When the signature data is successfully verified, the authentication data is stored in the authentication data list.

[0237] Exemplarily, the signature data may be verified. When the signature data is successfully verified, the authentication data is stored in an authentication data list.

[0238] Among them, the authentication data list may include multiple authentication data (including one or more authentication data obtained historically and authentication data currently obtained), and each authentication data may include: signature data, a second authentication identifier of each data unit in a group of data units, and second summary data of each data unit in a group of data units. The signature data is obtained by signing based on the second summary data of each data unit in a group of data units.

[0239] S405 , searching for authentication data matching the 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 identical to the multiple first authentication identifiers of the group of data units.

[0240] Then, the multiple first authentication identifiers obtained from the code stream can be compared with the multiple second authentication identifiers contained in each authentication data in the authentication data list; when authentication data containing multiple second authentication identifiers that are respectively identical to the multiple first authentication identifiers obtained from the code stream is found, the authentication data containing these multiple second authentication identifiers can be determined as authentication data that matches the multiple first authentication identifiers of a group of data units obtained from the code stream.

[0241] S406: Verify the plurality of first digest data of a group of data units according to the plurality of second digest data in the matched authentication data.

[0242] Exemplarily, after matching authentication data is found from the authentication data list, multiple second summary data (or summary data list) can be read from the matching authentication data; then, multiple first summary data of a group of data units are verified based on the multiple second summary data in the matching authentication data.

[0243] Specifically, for a first data unit in a group of data units obtained from the codestream (the first data unit may be any data unit in the group of data units obtained from the codestream), a search may be performed to determine whether second digest data identical to the first digest data of the first data unit exists among multiple second digest data in the matching authentication data. When second digest data identical to the first digest data of the first data unit is found among the multiple second digest data in the matching authentication data, authentication of the first data unit is determined to be successful, i.e., the authentication result may be "authentication success." Otherwise, authentication of the first data unit is determined to have failed, i.e., the authentication result may be "authentication failure."

[0244] For example, during implementation, the summary data list {summary data 21, summary data 22, ..., summary data 2n} can be made into a Map data structure, such as Map[summary data 21] = 1, Map[summary data 22] = 1, ..., Map[summary data 2n] = 1, to achieve fast search.

[0245] 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 authentication module in the authentication end 220 executed collaboratively (the decoder executes S401 and S403, and the authentication module executes S402, S404 to S406). This application does not impose any restrictions on this.

[0246] For the time-domain SVC encoding of the Surveillance Video and Audio Coding (SVAC) standard, each data unit uses temporal_id to identify its time-domain layer. During decoding, some time-domain layers or data units may not participate in decoding. In this application, since each data unit is independently summarized, during authentication, for data units participating in authentication, the corresponding summary data can be found in the authentication data. Data units not participating in authentication do not affect the authentication of other data units.

[0247] For the spatial domain SVC encoding of the SVAC standard, each data unit uses layer_id to identify the spatial domain layer it is in. During decoding, some spatial domain layers or data units may not participate in decoding; in this application, since each data unit has its own summary data, during authentication, for data units participating in authentication, the corresponding summary data can be found in the authentication data, and data units not participating in authentication will not affect the authentication of other data units.

[0248] For the video quality SVC encoding of the SVAC standard, during decoding, there may be certain quality levels or data units that do not participate in decoding. In this application, since each data unit has independent summary data, during authentication, for the data units participating in authentication, the corresponding summary data can be found in the authentication data, and the data units that do not participate in authentication will not affect the authentication of other data units.

[0249] In addition, for SVC coding, only one set of authentication data units needs to be transmitted to support authentication of the sub-bitstream extracted from the codestream.

[0250] In summary, this application can effectively solve the problem that the current SVC coding time domain SVC coding, spatial domain SVC coding, and video quality SVC coding require independent certification.

[0251] Secondly, because each data unit is independently authenticated, even if some data units are lost (frame loss), other data units can still be authenticated. In addition, because data units are identified with authentication identifiers, a one-to-one correspondence between data units and authentication data is guaranteed, avoiding the problem of mismatch between data units and authentication data due to long signature times.

[0252] For example, the authentication identifier of each data unit in a group of data units in the code stream can be located before the group of data units. In this way, the authenticator 220 can receive the authentication identifier of each data unit in the group of data units before receiving the group of data units. This ensures that the authenticator 220 marks each data unit in the received group of data units based on the authentication identifier of each data unit in the group of data units, determines the authentication identifier of each data unit, and ensures the correspondence between the data unit and the authentication data.

[0253] 5A is a schematic diagram illustrating an exemplary signing process 500. The process 500 may be implemented by the signing end 210. The process 500 is a process in which the SVAC signing end implements a data unit signature by using the security parameter set RBSP carrying the authentication identifier.

[0254] S501: Generate a security parameter set RBSP.

[0255] For example, when it is necessary to support video image authentication, a security parameter set RBSP (such as SEC_RBSP in FIG5A ) may be generated. The definition of the security parameter set RBSP in the NAL unit of the security parameter set may be as shown in Table 1:

[0256] Table 1 Security Parameter Set RBSP Definition

[0257] authentication_mode

[0258] 2-bit unsigned integer. Indicates the authentication mode used for authentication, which can be shown in Table 2:

[0259] Table 2 Authentication mode description

[0260] If authenticate_mode is 0, first concatenate the summary data of the image data (or data unit), perform summary data on the concatenated summary data, and then perform digital signature on the summary data.

[0261] Authentication serial number authentication_id

[0262] Binary variable. Authentication sequence number, used to identify the authentication data set it uses. A new authentication_id marks the beginning of a new authentication sequence (i.e., a new set of data units).

[0263] Hash type hash_type

[0264] 2-bit unsigned integer. Indicates the algorithm used for authentication (i.e., the algorithm used to determine the summary data of the data unit). The specific correspondence is shown in Table 3:

[0265] Table 3 Correspondence between hash types and specific algorithms

[0266] Digital signature type signature_type

[0267] 2-bit unsigned integer. Indicates the algorithm used to digitally sign the summary data of the data unit, as shown in Table 4 below:

[0268] Table 4 Correspondence between digital signature types and specific encryption algorithms

[0269] Authentication enable flag authentication_flag

[0270] 1-bit unsigned integer. Indicates whether a group of data units supports authentication, as shown in Table 5:

[0271] Table 5 Description of authentication enable flags

[0272] camera_idc is a 19-byte string that indicates the certificate identifier of the camera that is the source of the image corresponding to the stream.

[0273] It should be noted that, compared with the prior art, the security parameter set of the present application has newly added: authenticate_mode (which may be referred to as the first identifier) ​​and authentication_id (which may also be referred to as the authentication identifier).

[0274] 5A , SEC_RBSP may include n authentication identifiers: P1, P2, P3, P4, ..., Pn, where 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, ..., and Pn is the authentication identifier of data unit n.

[0275] For example, when authenticate_mode is 0, the codestream signature method described in this application may be used for signing, as described in S502 to S504 below. When authenticate_mode is 1, the signature method used in the prior art may be used for signing, i.e., calculating tree-type summary data and signing the tree-top summary data. Furthermore, when using the signature method described in this application, the authenticate_mode in the security parameter set RBSP may be set to 0 during the generation of the security parameter set RBSP.

[0276] Exemplarily, in the process of generating the security parameter set RBSP, the authentication_flag in the security parameter set RBSP may be set to 1, thereby indicating that a group of data units following the security parameter set RBSP supports authentication.

[0277] Exemplarily, when the data unit is a NAL unit, a group of data units may include multiple NAL units, each with a different authentication identifier. When the data unit is multiple NAL units, a group of data units may include multiple access units, each with a different authentication identifier, and each access unit may contain multiple NAL units with the same authentication identifier.

[0278] It should be noted that hash_type, signature_type and camera_idc in the security parameter set RBSP are optional.

[0279] S502: Calculate each data unit in a group of data units according to a digest algorithm to obtain digest data of each data unit in the group of data units.

[0280] Exemplarily, the number of data units that need to be authenticated may be determined according to the number of authentication_ids in the security parameter set RBSP; that is, the number of data units included in a group of data units.

[0281] In one possible approach, when the security parameter set RBSP includes hash_type, the digest algorithm may be the authentication algorithm indicated by hash_type in the security parameter set RBSP. In this case, a calculation may be performed on each data unit in a group of data units based on the authentication algorithm indicated by hash_type in the security parameter set RBSP to obtain digest data for each data unit in the group of data units. For example, a hash calculation may be performed on each data unit in a group of data units based on the digest algorithm indicated by hash_type in the security parameter set RBSP to obtain digest data for each data unit in the group of data units.

[0282] In one possible approach, the signing end 210 and the authenticating end 220 may pre-agreed on a digest algorithm. Thus, the digest data for each data unit in the set of data units can be calculated using the pre-agreed digest algorithm. In this case, the security parameter set RBSP may not include hash_type.

[0283] It should be understood that the present application does not limit the manner in which the signing end 210 and the authenticating end 220 synchronize the digest algorithms.

[0284] 5A again, illustratively, a hash calculation is performed on data unit 1 to obtain summary data H1; a hash calculation is performed on data unit 2 to obtain summary data H2; a hash calculation is performed on data unit 3 to obtain summary data H3; a hash calculation is performed on data unit 4 to obtain summary data H4; ...; a hash calculation is performed on data unit n to obtain summary data Hn.

[0285] S503 : Concatenate the summary data of each data unit in a group of data units, and determine the summary data of the summary data of each data unit in the concatenated group of data units.

[0286] Illustratively, the summary data of each data unit in a group of data units may be concatenated to obtain the concatenated summary data H1+H2+H3+H4+H5+...+Hn.

[0287] Next, the concatenated summary data may be calculated to obtain the summary data of the concatenated summary data. For example, H1+H2+H3+H4+H5+...+Hn may be hashed to obtain the summary data Hg of the concatenated summary data (as shown in FIG5A ).

[0288] S504: Use the private key to sign the summary data of the concatenated summary data to obtain signature data.

[0289] In one possible manner, when the security parameter set RBSP includes signature_type, the summary data of the concatenated summary data may be signed according to the signature algorithm and private key indicated by signature_type in the security parameter set RBSP to obtain signature data.

[0290] In one possible approach, the signing end 210 and the authenticating end 220 may pre-agreed on a signature algorithm. Thus, the concatenated summary data may be signed using the pre-agreed signature algorithm and private key to obtain the signature data. In this case, the security parameter set RBSP may not include signature_type.

[0291] It should be understood that the present application does not limit the manner in which the signing end 210 and the authenticating end 220 synchronize the signature algorithms.

[0292] It should be understood that it is also possible to generate tree-top summary data and use a private key to sign the tree-top summary data to obtain signature data. This application does not limit the method of signing based on the summary data of the data unit.

[0293] Exemplarily, the authentication data is generated according to the summary data of each data unit in a group of data units, the authentication identifier of each data unit in the group of data units, and the signature data.

[0294] For example, the authentication data may include {P1, P2, P3, P4, P5, ..., Pn, H1, H2, H3, H4, H5, ..., Hn, signature}.

[0295] S505: Encode the authentication data and add the encoded authentication data to the code stream.

[0296] For example, the authentication data may be encoded using Base64, and then the encoded authentication data may be packaged into a NAL unit of the authentication data. The definition of the authentication data RBSP in the NAL unit of the authentication data may be as shown in Table 6 below:

[0297] Table 6 Authentication data RBSP definition

[0298] Authentication serial number authentication_id

[0299] Binary variable. The certification serial number of the certification dataset.

[0300] Authentication summary data quantity authentication_hash_number_minus1

[0301] 8-bit unsigned integer. 1 is added to indicate the length of the signature data, in bytes, and the value should be between 0 and 255.

[0302] Authentication summary data authentication_hash

[0303] Binary data, with a length in bytes equal to the digest data length corresponding to the digest algorithm hash_type listed in the table of correspondence between hash types and specific algorithms in the security parameter set.

[0304] The length of the signature data authentication_data_length_minus1

[0305] 8-bit unsigned integer. 1 is added to indicate the length of the signature data, in bytes, and the value should be between 0 and 255.

[0306] The number of bytes of the signature data authentication_data[i]

[0307] 8-bit unsigned integer. The i-th byte of a signature data. The signature data should be Base64 encoded. See RFC 3548 for the Base64 encoding method.

[0308] Illustratively, the authentication identifier included in the authentication data is authentication_id (authentication serial number) in Table 6.

[0309] Illustratively, the digest data included in the authentication data is authentication_hash (authentication digest data) in Table 6.

[0310] Exemplarily, authentication_hash_number_minus1 in the authentication data RBSP may be referred to as a fourth identifier.

[0311] It should be noted that, compared with the authentication data RBSP in the prior art, the NAL unit of the authentication data of this application includes authentication_id, authentication_hash and authentication_hash_number_minus1.

[0312] In addition, in the time domain SVC coding scenario of the SVAC standard, each data unit includes a second identifier (temporal_id) for identifying the time domain layer of the data unit; correspondingly, the authentication data RBSP may also include the second identifier (temporal_id). Since the time domain base layer (i.e., the data unit with the second identifier of 0) needs to be parsed in the time domain SVC coding scenario of the SVAC standard, in order to ensure that the authentication data can be obtained during the authentication process regardless of whether the time domain enhancement layer is parsed, the value of the second identifier in the NAL unit of the authentication data can be set to 0

[0313] In the SVAC standard's spatial SVC coding or quality SVC coding scenario, each data unit includes a third identifier (layer_id) for identifying the spatial layer or quality coding layer at which the data unit is located; correspondingly, the authentication data RBSP may also include the third identifier (layer_id). Since the spatial base layer / quality coding base layer (i.e., the data unit with the third identifier of 0) needs to be parsed in the SVAC standard's spatial SVC coding or quality SVC coding scenario, in order to ensure that authentication data can be obtained during the authentication process regardless of whether the spatial enhancement layer / quality coding enhancement layer is parsed, the value of the third identifier in the NAL unit of the authentication data may be set to 0.

[0314] Figure 5B is a schematic diagram illustrating an exemplary signing process. Figure 5B shows two groups of data units in a code stream and the authentication data corresponding to the two groups of data units.

[0315] 5B , Sec represents the NAL unit of the security parameter set RESP, P1 to Pn correspond to a data unit respectively, Auth represents authentication data, Private Key refers to the private key, Sign refers to the signature, and Public Key refers to the public key.

[0316] 5B , in one possible approach, a public key may be added to the authentication data.

[0317] It should be understood that the public key corresponding to the above private key can also be transmitted through other means, such as being built into the authentication end, being placed in the authentication certificate and transmitted to the authentication end, etc. This application does not impose any restrictions on this.

[0318] It should be noted that the authentication data corresponding to the current group of data units may be connected after the current group of data units, as shown in the first group of data units and the authentication data of the first group of data units in Figure 5B. The authentication data corresponding to the current group of data units is not necessarily connected after the current group of data units, but may also be connected after the first few data units in the next group of data units (as shown in the second group of data units and the authentication data of the second group of data units in Figure 5B). This is due to the difference between the rate of encoding data units and the rate of generating authentication data. However, since the present application uses an authentication identifier to identify the data unit, a one-to-one correspondence between the data unit and the authentication data is guaranteed, thereby avoiding the problem of mismatch between the data unit and the authentication data due to a long signature time.

[0319] FIG6A is a schematic diagram illustrating an exemplary authentication process.

[0320] FIG6B is a schematic diagram illustrating an exemplary authentication process 600. Process 600 is a process by which the SVAC authenticator implements data unit authentication when the security parameter set RBSP carries an authentication identifier. Process 600 corresponds to process 500.

[0321] S601: Obtain a first authentication identifier of each data unit in a group of data units from a security parameter set RBSP of a code stream.

[0322] For example, after receiving the security parameter set RBSP for the codestream, the authenticator 220 parses the security parameter set RBSP for the codestream and finds that the authentication_flag is 1. The authenticator 220 determines that the subsequent set of data units supports authentication. At this point, the authenticator 220 can continue parsing the syntax elements in the security parameter set RBSP in the order of the syntax elements in Table 1.

[0323] Exemplarily, the hash_mode in the security parameter set RBSP is parsed; when the hash_mode obtained from the parsing is 0, S602 may be executed.

[0324] Exemplarily, by parsing the authentication_id in the security parameter set RBSP, the first authentication identifier of each data unit in a group of data units can be obtained.

[0325] Exemplarily, the hash_type in the security parameter set RBSP is parsed; and the digest algorithm is determined according to the value of the hash_type obtained by parsing.

[0326] Exemplarily, the signature_type in the security parameter set RBSP is parsed; and the signature algorithm is determined according to the value of the signature_type obtained by parsing.

[0327] Exemplarily, the camera_idc in the security parameter set RBSP is parsed; and according to the value of the camera_idc obtained by parsing, the certificate identifier of the camera that is the source of the image corresponding to the code stream is determined.

[0328] 6A , illustratively, the n first authentication identifiers are: P1, P2, P3, P4, . . . , Pn.

[0329] S602: Calculate each data unit in a group of data units according to a digest algorithm to obtain first digest data of each data unit in the group of data units.

[0330] For example, when the authentication end 220 receives each data unit of a subsequent group of data units, it can record the corresponding authentication identifier for the NAL unit of each data unit; and calculate each data unit in a group of data units to obtain the first summary data of each data unit in a group of data units.

[0331] In one possible approach, when hash_type is parsed from the security parameter set RBSP of the code stream, each data unit in a group of data units can be calculated according to the authentication algorithm (i.e., digest algorithm) indicated by hash_type to obtain the first digest data of each data unit in the group of data units.

[0332] For example, a hash calculation may be performed on each data unit in a group of data units 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 group of data units.

[0333] In one possible approach, when hash_type is not parsed from the security parameter set RBSP of the codestream, each data unit in a group of data units may be calculated according to a pre-agreed digest algorithm to obtain digest data of each data unit in the group of data units.

[0334] 6A , illustratively, the n first summary data are: H1 ′, H2 ′, H3 ′, H4 ′, H5 ′, . . . , Hn ′.

[0335] S603, obtaining authentication data from the code stream, the authentication data including: signature data, a second authentication identifier of each data unit in a group of data units, and second summary data of each data unit in a group of data units, the signature data being obtained by signing the second summary data of each data unit in the group of data units.

[0336] Exemplarily, the authentication data RBSP in the code stream may be parsed to obtain the authentication data.

[0337] Exemplarily, the authentication_id in the authentication data RBSP is parsed to obtain the second authentication identifier of each data unit in a group of data units.

[0338] Exemplarily, the authentication_hash_number_minus1 (also referred to as the fourth identifier) ​​in the authentication data RBSP is parsed to obtain the number of second digest data included in the authentication data.

[0339] Exemplarily, authentication_hash in the authentication data RBSP is parsed according to authentication_hash_number_minus1 to obtain second summary data of each data unit in a group of data units; wherein the number of the second summary data is the same as the value calculated according to authentication_hash_number_minus1.

[0340] Exemplarily, when the authentication data generated in the signing end 210 also includes a public key corresponding to the private key used for signing, the public key can also be parsed from the authentication data RBSP.

[0341] Exemplarily, the authentication data may include {P1, P2, P3, P4, P5, ..., Pn, H1, H2, H3, H4, H5, ..., Hn, signature}

[0342] S604: Verify the signature data according to the public key, the first summary data of each data unit in a group of data units, and the signature algorithm.

[0343] For example, the first digest data of each data unit in a group of data units can be concatenated. Next, the digest data Hg' of the concatenated first digest data can be determined. A signature verification algorithm corresponding to the signature algorithm can then be used to process the public key, Hg', and the signature data to obtain a verification result for the signature data.

[0344] In one possible approach, when the signature_type is parsed from the codestream security parameter set RBSP, the signature algorithm may be determined according to the signature algorithm indicated by the signature_type.

[0345] In one possible approach, the signature algorithm may be determined according to a pre-agreed signature algorithm.

[0346] One possible approach is to find the public key in the authentication certificate indicated by camera_idc when the camera_idc is obtained from the security parameter set RBSP of the codestream.

[0347] In one possible approach, the public key may be parsed from the authentication data RBSP of the code stream.

[0348] In one possible approach, a public key pre-built into the authentication terminal 220 may be obtained.

[0349] S605: When the signature data is successfully verified, the authentication data is stored in the authentication data list.

[0350] S606: Search the authentication data list for authentication data that matches the multiple first authentication identifiers of a group of data units; wherein the matching authentication data includes multiple second authentication identifiers that are respectively identical to the multiple first authentication identifiers of the group of data units.

[0351] S607: Verify the plurality of first digest data of a group of data units according to the plurality of second digest data in the matched authentication data.

[0352] For example, S605 to S607 may refer to the description of S404 to S406 above and will not be repeated here.

[0353] Exemplarily, in S607, the plurality of second digest data in the matched authentication data may be {H1, H2, H3, H4, H5, ..., Hn}, and the plurality of first digest data in a group of data units may be {H1', H2', H3', H4', H5', ..., Hn'}; from {H1, H2, H3, H4, H5, ..., Hn}, each first digest data in {H1', H2', H3', H4', H5', ..., Hn'} is searched. For example, when the 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 the 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 repeated here. If the second summary 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 has failed; if the second summary 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 has failed; and so on.

[0354] 7 is a schematic diagram illustrating an exemplary signing process 700. The process 700 may be implemented by the signing end 210. The process 700 is a process in which the signing end implements a data unit signature by carrying an authentication identifier in extended information.

[0355] For example, H264 video encoding includes CEI extension information in SEI information with NAL unit type 6, and H265 video encoding includes CEI extension information in SEI information with NAL unit type 39. CEI data of the AVS series standard is carried in extension_data after the sequence_header. This application extends the CEI syntax to support authentication of NAL units; wherein, the appearance of the new CEI syntax supporting authentication indicates the start of a new authentication.

[0356] S701: Generate extended information.

[0357] For example, when video image authentication is required, CEI extended information (or CEI data) may be generated, as shown in Table 7:

[0358] Table 7 CEI data syntax format

[0359] authentication_flag: identifies whether the video data (or data unit) following the extended data is authenticated;

[0360] authentication_id: authentication serial number, used to identify the authentication data set used. A new authentication_id marks the beginning of a new authentication sequence.

[0361] hash_type: Hash type, indicating the algorithm used for authentication. The specific correspondence is shown in Table 8 below:

[0362] Table 8 Correspondence between hash types and specific algorithms

[0363] signature_type: digital signature type, indicating the algorithm used to digitally sign the summary data of the image (or data unit), as shown in Table 9 below:

[0364] Table 9 Correspondence between digital signature types and specific encryption algorithms

[0365] It should be noted that, compared with the prior art, the CEI extended information of this application is newly added with: authentication_id (also known as authentication identifier), hash_type, signature_type and authentication_flag.

[0366] Exemplarily, in the process of generating the CEI extension information, the authentication_flag in the CEI extension information may be set to 1, thereby indicating that a group of data units following the CEI extension information supports authentication.

[0367] Exemplarily, when the data unit is a NAL unit, a group of data units may include multiple NAL units, each with a different authentication identifier. When the data unit is multiple NAL units, a group of data units may include multiple access units, each with a different authentication identifier, and each access unit may contain multiple NAL units with the same authentication identifier.

[0368] It should be noted that hash_type and signature_type in the extended information are optional.

[0369] S702: Calculate each data unit in a group of data units according to a digest algorithm to obtain digest data of each data unit in the group of data units.

[0370] Exemplarily, the number of data units that need to be authenticated may be determined according to the number of authentication_ids in the CEI extended information; that is, the number of data units included in a group of data units.

[0371] For example, S702 may refer to the description of S502 above, which will not be repeated here.

[0372] The difference between S702 and S502 is that, in a possible manner of S702, the digest algorithm may be the authentication algorithm indicated by hash_type in the CEI extended information.

[0373] S703: Concatenate the summary data of each data unit in a group of data units, and determine the summary data of the summary data of each data unit in the concatenated group of data units.

[0374] S704 , using a private key to sign the summary data of each data unit in the connected set of data units to obtain signature data.

[0375] For example, S703 to S704 may refer to the description of S503 to S504 above, which will not be repeated here.

[0376] The difference between S704 and S504 is that in one possible manner of S704, the signature algorithm may be the signature algorithm indicated by signature_type in the CEI extended information.

[0377] S705: Encode the authentication data and add the encoded authentication data to the code stream.

[0378] For example, S702 to S705 may refer to the description of S502 to S505 above, which will not be repeated here.

[0379] For example, the authentication data RBSP definition in process 700 may be as shown in Table 10 below:

[0380] Table 10 Authentication data RBSP definition

[0381] Authentication serial number authentication_id

[0382] Binary variable. The certification serial number of the certification dataset.

[0383] Authentication summary data quantity authentication_hash_number_minus1

[0384] 8-bit unsigned integer. 1 is added to indicate the length of the signature data, in bytes, and the value should be between 0 and 255.

[0385] Authentication summary data authentication_hash

[0386] Binary data, with a length in bytes equal to the digest data length corresponding to the digest algorithm hash_type listed in the table of correspondence between hash types and specific algorithms in the security parameter set.

[0387] The length of the signature data authentication_data_length_minus1

[0388] 8-bit unsigned integer. 1 is added to indicate the length of the signature data, in bytes, and the value should be between 0 and 255.

[0389] The number of bytes of the signature data authentication_data[i]

[0390] The i-th byte of the signature data.

[0391] It should be noted that the authentication data RBSP generated in process 700 is newly added.

[0392] Signature certificate chain length certificate_chain_length_minus1

[0393] The length of the certificate chain used to verify the signature. 1 is added to indicate the length of the signature data. The value is in bytes and should be between 0 and 65535. A value of 1 indicates no certificate chain.

[0394] Signature certificate chain certificate_chain_data[i]

[0395] The i-th byte of the signing certificate chain.

[0396] It should be noted that certificate_chain_data and certificate_chain_length_minus1 are optional.

[0397] In addition, in the time-domain SVC encoding scenario of the SVAC standard, each data unit includes a second identifier (temporal_id) for identifying the time-domain layer of the data unit; correspondingly, the authentication data RBSP may also include the second identifier (temporal_id). Since in the time-domain SVC encoding scenario of the SVAC standard, the time-domain base layer (i.e., the data unit with the second identifier of 0) needs to be parsed, in order to ensure that the authentication data can be obtained during the authentication process regardless of whether the time-domain enhancement layer is parsed; the value of the second identifier in the NAL unit of the authentication data can be set to 0.

[0398] In the SVAC standard's spatial SVC coding or quality SVC coding scenario, each data unit includes a third identifier (layer_id) for identifying the spatial layer or quality coding layer at which the data unit is located; correspondingly, the authentication data RBSP may also include the third identifier (layer_id). Since the spatial base layer / quality coding base layer (i.e., the data unit with the third identifier of 0) needs to be parsed in the SVAC standard's spatial SVC coding or quality SVC coding scenario, in order to ensure that authentication data can be obtained during the authentication process regardless of whether the spatial enhancement layer / quality coding enhancement layer is parsed, the value of the third identifier in the NAL unit of the authentication data may be set to 0.

[0399] In process 700, the public key may also be added to the authentication data (the public key may be in the signature certificate chain certificate_chain_data). It should be understood that the public key corresponding to the private key may also be transmitted in other ways, such as being built into the authentication end, being placed in a certificate and transmitted to the authentication end, etc., and this application does not limit this.

[0400] FIG8A is a schematic diagram illustrating an exemplary authentication process.

[0401] FIG8B is a schematic diagram illustrating an exemplary authentication process 600. Process 800 is a process in which the authenticator implements data unit authentication when the extended information carries the authentication identifier. Process 800 corresponds to process 700.

[0402] S801: Obtain a first authentication identifier of each data unit in a group of data units from extended information of a code stream.

[0403] For example, after receiving the CEI extension information of the code stream, the authenticator determines that the subsequent set of data units supports authentication when the authentication_flag in the CEI extension information of the code stream is 1. At this time, the syntax elements in the CEI extension information can be parsed in the order of the syntax elements in Table 7.

[0404] Exemplarily, by parsing the authentication_id in the CEI extended information, the first authentication identifier of each data unit in a group of data units can be obtained.

[0405] Exemplarily, the hash_type in the CEI extended information is parsed; and the digest algorithm is determined according to the value of the hash_type obtained by parsing.

[0406] Exemplarily, the signature_type in the CEI extended information is parsed; and the signature algorithm is determined according to the value of the signature_type obtained by parsing.

[0407] 8A , illustratively, the n first authentication identifiers are: P1, P2, P3, P4, . . . , Pn.

[0408] S802: Calculate each data unit in a group of data units according to a digest algorithm to obtain first digest data of each data unit in the group of data units.

[0409] For example, S802 may refer to the description of S602 above, which will not be repeated here.

[0410] The difference between S802 and S602 is that, in a possible manner of S802, the digest algorithm may be determined according to hash_type parsed from the CEI extension information of the code stream.

[0411] S803, obtaining authentication data from the code stream, the authentication data including: signature data, a second authentication identifier for each data unit in a group of data units, and second summary data for each data unit in a group of data units, the signature data being obtained by signing the second summary data for each data unit in the group of data units.

[0412] For example, S803 may refer to the description of S603 above, which will not be repeated here.

[0413] S804: Verify the signature data according to the public key, the first summary data of each data unit in a group of data units, and the signature algorithm.

[0414] For example, S804 may refer to the description of S604 above, which will not be repeated here.

[0415] The difference between S804 and S604 is that, in one possible implementation of S804, the signature algorithm can be determined based on the signature_type parsed from the CEI extension information of the codestream. Furthermore, because the CEI extension information of the codestream does not include camera_idc, S804 does not include a method for determining the public key based on camera_idc.

[0416] S805: When the signature data is successfully verified, the authentication data is stored in the authentication data list.

[0417] S806, searching for authentication data matching the 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 identical to the multiple first authentication identifiers of the group of data units.

[0418] S807: Verify the plurality of first digest data of a group of data units according to the plurality of second digest data in the matched authentication data.

[0419] For example, S805 to S807 may refer to the description of S605 to S607 above and will not be repeated here.

[0420] FIG9 is a schematic diagram illustrating an exemplary signing process 900. Process 900 may be implemented by the signing terminal 210. Process 900 is a process in which the SVAC signing terminal implements data unit signing by carrying an authentication identifier in a NAL header.

[0421] For example, when video image authentication needs to be supported, a security parameter set RBSP is generated; wherein the security parameter set RBSP definition may be as shown in Table 11 below:

[0422] Table 11 Security Parameter Set RBSP Definition

[0423] Among them, the description of the syntax elements in Table 11 can refer to the description of the syntax elements in the above Table 6, and will not be repeated here.

[0424] It should be noted that, compared with the prior art, the security parameter set of this application adds: authentication_mode (which can be called the first identifier).

[0425] Exemplarily, the authentication_flag in the security parameter set RBSP may also be set to 1, thereby indicating that a group of data units following the security parameter set RBSP supports authentication.

[0426] It should be noted that hash_type, signature_type and camera_idc in the security parameter set RBSP are optional.

[0427] S901: Generate NAL unit.

[0428] For example, the NAL unit syntax table may be as shown in Table 12:

[0429] Table 12 NAL unit syntax table

[0430] Authentication serial number authentication_id

[0431] A binary variable. The value of authentication_idc is '1', indicating the authentication sequence number, which is used to identify the authentication dataset used.

[0432] Authentication enable flag authentication_idc

[0433] A binary variable indicating whether the NAL unit is authenticated. A value of '0' indicates that the NAL unit is not authenticated, and a value of '1' indicates that the NAL unit is authenticated using the authentication method specified in the security parameter set.

[0434] Temporal level identifier temporal_id

[0435] 3-bit unsigned integer indicating the temporal level of the NAL unit.

[0436] It should be noted that, compared with the prior art, the data unit of the present application includes a NAL unit with a newly added authentication_id (also called an authentication identifier).

[0437] Exemplarily, during the process of generating a NAL unit, the value of authentication_idc may be set to 1; in this way, it may be indicated that the NAL unit requires authentication.

[0438] S902: Calculate each data unit in a group of data units according to a digest algorithm to obtain digest data of each data unit in the group of data units.

[0439] Exemplarily, the number of data units that need to be authenticated may be determined based on the authentication_id obtained from the NAL unit; that is, the number of data units included in a group of data units.

[0440] For example, if authentication_ids are obtained from 100 NAL units, and the 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.

[0441] For another example, if authentication_ids are obtained from 100 NAL units, and every 10 authentication_ids among the 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.

[0442] S903: Concatenate the summary data of each data unit in a group of data units, and determine the summary data of the summary data of each data unit in the concatenated group of data units.

[0443] S904: Use the private key to sign the summary data of each data unit in the connected group of data units to obtain signature data.

[0444] S905: Encode the authentication data and add the encoded authentication data to the code stream.

[0445] For example, S902 to S905 may refer to the description of S502 to S505 above, which will not be repeated here.

[0446] Among them, the definition of authentication data RBSP can refer to the above Table 6 and will not be repeated here.

[0447] In addition, in the time-domain SVC coding scenario of the SVAC standard, each data unit includes a second identifier (temporal_id) for identifying the time-domain layer of the data unit; correspondingly, the authentication data RBSP may also include the second identifier (temporal_id). Since the time-domain base layer (i.e., the data unit with the second identifier of 0) needs to be parsed in the time-domain SVC coding scenario of the SVAC standard, in order to ensure that the authentication data can be obtained during the authentication process regardless of whether the time-domain enhancement layer is parsed, the value of the second identifier in the NAL unit of the authentication data can be set to 0.

[0448] In the spatial SVC coding or quality SVC coding scenario of the SVAC standard, each data unit includes a third identifier (layer_id) for identifying the spatial layer or quality coding layer of the data unit; correspondingly, the authentication data RBSP may also include the third identifier (layer_id. Since the spatial base layer / quality coding base layer (i.e., the data unit with the third identifier of 0) needs to be parsed in the spatial SVC coding or quality SVC coding scenario of the SVAC standard, in order to ensure that the authentication data can be obtained during the authentication process regardless of whether the spatial enhancement layer / quality coding enhancement layer is parsed, the value of the third identifier in the NAL unit of the authentication data can be set to 0.

[0449] In process 900, the public key may also be added to the authentication data. It should be understood that the public key corresponding to the private key may also be transmitted in other ways, such as being built into the authentication terminal, being placed in a certificate and transmitted to the authentication terminal, etc., and this application does not limit this.

[0450] FIG. 10A is a schematic diagram illustrating an exemplary authentication process.

[0451] 10B is a schematic diagram illustrating an exemplary authentication process 1000. The process 1000 may be implemented by the authentication terminal 220. The process 1000 is a process in which the SVAC authentication terminal implements data unit authentication when the NAL header carries an authentication identifier.

[0452] For example, after receiving the security parameter set RBSP for the codestream, the authenticator 220 determines that the subsequent set of data units supports authentication when the authentication_flag in the security parameter set RBSP is 1. At this point, the parse sequence of the syntax elements in the security parameter set RBSP can be continued according to the order of the syntax elements in Table 1.

[0453] Exemplarily, the hash_mode in the security parameter set RBSP is parsed; when the hash_mode obtained from the parsing is 0, S602 may be executed.

[0454] Exemplarily, the hash_type in the security parameter set RBSP is parsed; and the digest algorithm is determined according to the value of the hash_type obtained by parsing.

[0455] Exemplarily, the signature_type in the security parameter set RBSP is parsed; and the signature algorithm is determined according to the value of the signature_type obtained by parsing.

[0456] Exemplarily, the camera_idc in the security parameter set RBSP is parsed; and according to the value of the camera_idc obtained by parsing, the authentication certificate identifier of the camera of the image source corresponding to the code stream is determined.

[0457] S1001: Obtain a first authentication identifier of a NAL unit from a code stream.

[0458] Exemplarily, when the authentication end 220 receives a NAL unit, it parses the NAL unit to obtain authentication_idc; when authentication_idc is 1, it may continue to parse the NAL unit to obtain the first authentication identifier in the NAL unit.

[0459] S1002: Calculate each data unit in a group of data units according to a digest algorithm to obtain first digest data of each data unit in the group of data units.

[0460] For example, S1002 may refer to the description of S602 above, which will not be repeated here.

[0461] Illustratively, the present application does not limit the execution order of S1001 and S1002.

[0462] S1003, obtaining authentication data from the code stream, the authentication data including: signature data, a second authentication identifier of each data unit in a group of data units, and second summary data of each data unit in a group of data units, the signature data being obtained by signing the second summary data of each data unit in the group of data units.

[0463] S1004: Verify the signature data according to the public key, the first summary data of each data unit in a group of data units, and the signature algorithm.

[0464] S1005: When the signature data is successfully verified, the authentication data is stored in the authentication data list.

[0465] S1006 , searching for authentication data matching the 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 identical to the multiple first authentication identifiers of the group of data units.

[0466] S1007 , verifying the plurality of first digest data of a group of data units according to the plurality of second digest data in the matched authentication data.

[0467] For example, S1003 to S807 may refer to the description of S603 to S607 above and will not be repeated here.

[0468] It should be understood that, in one possible approach, both the security parameter set and the NAL unit included in the data unit include the authentication identifier. In one possible approach, both the extended information and the NAL unit included in the data unit include the authentication identifier. In one possible approach, both the security parameter set and the extended information include the authentication identifier.

[0469] Figure 11 is a schematic diagram of an exemplary code stream signature device. This schematic diagram of the code stream signature device can be used to implement the method of the aforementioned embodiment. Therefore, the beneficial effects achieved by the device can refer to the beneficial effects of the corresponding method provided above and will not be repeated here.

[0470] The code stream includes: a group of data units and an authentication identifier of each data unit in the group of data units,

[0471] 11 , a code stream signature device 1100 may include:

[0472] A first authentication data acquisition module 1101 is configured to acquire authentication data; wherein the authentication data includes signature data, an authentication identifier of each data unit in a set of data units, and summary data of each data unit in the set of data units, wherein the signature data is obtained by signing the summary data of each data unit in the set of data units;

[0473] The adding module 1102 is used to add the authentication data to the code stream.

[0474] Exemplarily, the code stream signature device 1100 further includes:

[0475] The summary data calculation module is used to calculate each data unit in a group of data units according to a summary algorithm to obtain summary data of each data unit in the group of data units.

[0476] Exemplarily, the summary data calculation module is further configured to concatenate summary data of each data unit in a group of data units to determine summary data of the concatenated summary data;

[0477] The code stream signature device 1100 further includes:

[0478] The signature module is used to sign the summary data of the connected summary data using a private key to obtain signature data.

[0479] Exemplarily, the code stream signature device 1100 further includes:

[0480] 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 group of data units and the summary data of each data unit in the group of data units.

[0481] Exemplarily, the adding module 1102 is specifically configured to encode the authentication data and add the encoded authentication data to the code stream.

[0482] Illustratively, each data unit in a group of data units includes one or more network abstraction layer NAL units.

[0483] For example, 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 continuous. That is, one data unit is an access unit.

[0484] Illustratively, each data unit in a set of data units comprises an encoded image.

[0485] Exemplarily, each NAL unit includes an authentication identifier of the data unit to which it belongs.

[0486] Illustratively, the authentication identifier of each data unit in a group of data units in the code stream is located before the group of data units.

[0487] Exemplarily, the code stream further includes a security parameter set, and the security parameter set includes an authentication identifier of each data unit in a group of data units.

[0488] Exemplarily, the code stream further includes extended information, and the extended information includes an authentication identifier of each data unit in a group of data units.

[0489] Exemplarily, the code stream further includes a first identifier, which indicates an authentication mode adopted by a group of data units.

[0490] Exemplarily, the code stream further includes a security parameter set, and the security parameter set includes a first identifier.

[0491] Exemplarily, the code stream further includes a NAL unit of authentication data, and the NAL unit of the authentication data includes a second identifier; wherein the second identifier indicates a time domain layer, and a value of the second identifier is 0.

[0492] Exemplarily, the code stream further includes a NAL unit of authentication data, and the NAL unit of the authentication data includes a third identifier; wherein the third identifier indicates a spatial level or a quality coding level, and a value of the third identifier is 0.

[0493] Figure 12 is a schematic diagram of an exemplary code stream authentication device. The code stream authentication device schematic diagram can be used to implement the method of the aforementioned embodiment. Therefore, the beneficial effects that can be achieved can refer to the beneficial effects of the corresponding method provided above and will not be repeated here.

[0494] 12 , the code stream authentication device 1200 includes:

[0495] The authentication identifier acquisition module 1201 is configured to acquire a first authentication identifier of each data unit in a group of data units from a bitstream;

[0496] A summary data determination module 1202 is configured to determine first summary data of each data unit in a group of data units;

[0497] A second authentication data acquisition module 1203 is configured to acquire authentication data from the code stream, the authentication data including signature data, a second authentication identifier for each data unit in a group of data units, and second digest data for each data unit in the group of data units. The signature data is obtained by signing the second digest data of each data unit in the group of data units.

[0498] The authentication data storage module 1204 is used to store the authentication data in the authentication data list when the signature data is successfully verified;

[0499] The authentication data search module 1205 is configured to search the authentication data list for authentication data that matches the plurality of first authentication identifiers of a group of data units; wherein the matching authentication data includes a plurality of second authentication identifiers that are respectively identical to the plurality of first authentication identifiers of the group of data units;

[0500] The verification module 1206 is configured to verify the plurality of first digest data of a group of data units according to the plurality of second digest data in the matched authentication data.

[0501] Illustratively, the summary data determining module 1202 is specifically configured to calculate each data unit in a group of data units according to a summary algorithm to obtain first summary data of each data unit in the group of data units.

[0502] Exemplarily, the code stream authentication device 1200 further includes:

[0503] Public key acquisition module, used to obtain the public key;

[0504] The summary data determining module 1202 is further configured to concatenate the second summary data of each data unit in a group of data units and determine summary data of the concatenated second summary data;

[0505] 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 the signature algorithm.

[0506] Exemplarily, the code stream authentication device 1200 further includes:

[0507] An identification acquisition module, configured to acquire a first identification from a code stream, the first identification indicating an authentication mode adopted by a group of data units;

[0508] When the value of the first identifier is a first preset value, the summary data determination module is configured to determine first summary data of each data unit in a group of data units.

[0509] 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 group of data units includes n data units, and n is a positive integer;

[0510] Exemplarily, the code stream authentication device 1200 further includes:

[0511] The summary data acquisition module is used to acquire second summary data of each data unit in the n data units from the code stream.

[0512] Illustratively, each data unit in a group of data units includes one or more network abstraction layer NAL units.

[0513] For example, 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 continuous. That is, one data unit is an access unit.

[0514] Illustratively, each data unit in a set of data units comprises an encoded image.

[0515] Exemplarily, the verification module 1206 is specifically used for the first data unit in a group of data units: if the second summary data identical to the first summary data of the first data unit is found in the multiple second summary data in the matching 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 has failed.

[0516] In an example, FIG13 shows a schematic block diagram of a device 1300 according to an embodiment of the present application. The device 1300 may include: a processor 1301 and a transceiver / transceiver pin 1302 , and optionally, a memory 1303 .

[0517] The various components of the device 1300 are coupled together via a bus 1304, wherein the bus 1304 includes, in addition to a data bus, a power bus, a control bus, and a status signal bus. However, for the sake of clarity, all buses are referred to as bus 1304 in the figure.

[0518] Optionally, the memory 1303 may be used to store instructions in the aforementioned method embodiment. The processor 1301 may be used to execute the instructions in the memory 1303 and control the receiving pin to receive a signal and control the transmitting pin to send a signal.

[0519] The apparatus 1300 may be the electronic device or a chip of the electronic device in the above method embodiment.

[0520] Among them, all relevant contents of each step involved in the above method embodiment can be referred to the functional description of the corresponding functional module and will not be repeated here.

[0521] The present application also provides a chip including one or more interface circuits and one or more processors; the one or more processors receive or send data via the one or more interface circuits, and when the one or more processors execute computer instructions, the steps of the above-mentioned related methods are implemented. The interface circuit is transceiver / transceiver pin 1302.

[0522] This embodiment further provides a computer-readable storage medium, in which computer instructions are stored. When the computer instructions are executed on an electronic device, the electronic device executes the above-mentioned related method steps to implement the method in the above-mentioned embodiment.

[0523] 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 executes the above-mentioned related steps to implement the method in the above-mentioned embodiment.

[0524] In addition, an embodiment of the present application also provides a device, which can specifically be a chip, component or module, and the device may include a connected processor and memory; wherein the memory is used to store computer-executable instructions, and when the device is running, the processor can execute the computer-executable instructions stored in the memory to enable the chip to execute the methods in the above-mentioned method embodiments.

[0525] 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 methods provided above. Therefore, the beneficial effects that can be achieved can refer to the beneficial effects in the corresponding methods provided above, and will not be repeated here.

[0526] Through the description of the above implementation methods, technical personnel in the relevant field can understand that for the convenience and simplicity of description, only the division of the above-mentioned functional modules is used as an example. In actual applications, the above-mentioned functions can be distributed and completed by different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0527] In the several embodiments provided in this 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 schematic. For example, the division of modules or units is only a logical function division. In actual implementation, there may be other division methods, such as 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 mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0528] Units described as separate components may or may not be physically separate, and components shown as units may be one physical unit or multiple physical units, that is, they may be located in one place or distributed in multiple places. Some or all of the units may be selected according to actual needs to achieve the purpose of the present embodiment.

[0529] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0530] Any content of each embodiment of this application, as well as any content of the same embodiment, can be freely combined. Any combination of the above content is within the scope of this application.

[0531] 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 this understanding, the technical solution of the embodiment of the present application is essentially 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, which is stored in a storage medium and includes several instructions for enabling a device (which can be a single-chip microcomputer, chip, etc.) or a processor (processor) to execute all or part of the steps of the various embodiments of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0532] The steps of the method or algorithm described in conjunction with the disclosure of the embodiments of the present application can be implemented in a hardware manner, or can be implemented by a processor executing a software instruction. The software instruction can be composed of corresponding software modules, and the software module can be stored in a random access memory (Random Access Memory, RAM), a flash memory, a read-only memory (Read Only Memory, ROM), an erasable programmable read-only memory (Erasable Programmable ROM, EPROM), an electrically erasable programmable read-only memory (Electrically EPROM, EEPROM), a register, a hard disk, a mobile hard disk, a read-only compact disc (CD-ROM) or any other form of storage medium well known in the art. An exemplary storage medium is coupled to a processor so that the processor can read information from the storage medium and can write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and the storage medium can be located in an ASIC.

[0533] Those skilled in the art will appreciate that in one or more of the above examples, the functions described in the embodiments of the present application can be implemented using 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. Computer-readable media include computer-readable storage media and communication media, wherein communication media include any media that facilitates the transmission of computer programs from one place to another. The storage medium can be any available medium that can be accessed by a general-purpose or special-purpose computer.

[0534] The embodiments of the present application are described above in conjunction with the accompanying drawings, but the present application is not limited to the above-mentioned specific implementation methods. The above-mentioned specific implementation methods are merely illustrative and not restrictive. Under the guidance of this application, ordinary technicians in this field can also make many forms without departing from the purpose of this application and the scope of protection of the claims, all of which are within the protection of this application.

Claims

1. A bit stream signature method, characterized in that: The bit stream includes: a group of data units and an authentication identifier of each data unit in the group of data units, and the method includes: Acquire authentication data; wherein the authentication data includes: signature data, an authentication identifier of each data unit in the set of data units, and summary data of each data unit in the set of data units, wherein the signature data is obtained by signing the summary data of each data unit in the set of data units; The authentication data is added to the bit stream.

2. The method according to claim 1, characterized in that The method further comprises: Each data unit in the group of data units is calculated according to a digest algorithm to obtain digest data of each data unit in the group of data units.

3. The method according to claim 2, characterized in that The digest algorithm is a digest algorithm indicated by a hash type hash_type, and the hash_type is parsed from a security parameter set RBSP of the bitstream.

4. The method according to any one of claims 1 to 3, characterized in that: The method further comprises: The summary data of each data unit in the group of data units is concatenated to determine summary data of the concatenated summary data.

5. The method according to claim 4, characterized in that The method further comprises: The summary data of the concatenated summary data is signed to obtain the signature data.

6. The method according to any one of claims 1 to 5, characterized in that: The method further comprises: The authentication data is generated according to the signature data, the authentication identifier of each data unit in the group of data units, and the summary data of each data unit in the group of data units.

7. The method according to any one of claims 1 to 6, characterized in that: The authentication data includes a summary data list, which is composed of summary data of each data unit in the group of data units.

8. The method according to any one of claims 1 to 7, characterized in that: Each data unit in the set of data units includes one or more network abstraction layer NAL units.

9. The method according to claim 8, characterized in that The NAL unit includes an authentication enable flag authentication_idc, and the authentication_idc is used to indicate whether the NAL unit supports authentication.

10. The method according to claim 8 or 9, 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 bit stream further includes a first identifier, which indicates an authentication mode adopted by the group of data units.

12. The method according to claim 11, characterized in that The bitstream further includes a security parameter set, and the security parameter set includes the first identifier.

13. The method according to any one of claims 1 to 12, characterized in that: The bit stream further includes a NAL unit of authentication data, and the NAL unit of authentication data includes a second identifier; wherein the second identifier is temporal_id, which is used to indicate a temporal domain layer, and the value of the temporal_id is 0.

14. The method according to any one of claims 1 to 12, characterized in that: The bit stream further includes a NAL unit of authentication data, wherein the NAL unit of authentication data includes a third identifier; wherein the third identifier is layer_id, which is used to indicate a spatial domain layer, and a value of layer_id is 0.

15. A bit stream, characterized in that The bit stream comprises: a set of data units, authentication data, and an authentication identifier for each data unit in the set of data units; The authentication data includes: signature data, an authentication identifier of each data unit in the group of data units, and summary data of each data unit in the group of data units, and the signature data is obtained by signing the summary data of each data unit in the group of data units.

16. The bit stream according to claim 15, characterized in that The authentication data includes a summary data list, which is composed of summary data of each data unit in the group of data units.

17. The bit stream according to claim 15 or 16, characterized in that Each data unit in the set of data units includes one or more network abstraction layer NAL units.

18. The bit stream according to claim 17, characterized in that The NAL unit includes an authentication enable flag authentication_idc, and the authentication_idc is used to indicate whether the NAL unit supports authentication.

19. The bit stream according to claim 17 or 18, characterized in that Each NAL unit includes the authentication identifier of the data unit to which it belongs.

20. The bit stream according to any one of claims 15 to 19, characterized in that The bit stream further includes a first identifier, which indicates an authentication mode adopted by the group of data units.

21. The bit stream according to claim 20, characterized in that The bitstream further includes a security parameter set, and the security parameter set includes the first identifier.

22. The bit stream according to any one of claims 15 to 21, characterized in that The bit stream further includes a NAL unit of authentication data, and the NAL unit of authentication data includes a second identifier; wherein the second identifier is temporal_id, which is used to indicate a temporal domain layer, and the value of the temporal_id is 0.

23. A bit stream according to any one of claims 15 to 21, characterized in that The bit stream further includes a NAL unit of authentication data, and the NAL unit of authentication data includes a third identifier; wherein the third identifier is layer_id, which is used to indicate a spatial domain layer, and the value of layer_id is 0.

24. The code stream according to any one of claims 15 to 22, characterized in that: The authentication data further includes a fourth identifier, and the fourth identifier is used to determine the amount of summary data included in the authentication data.

25. A method for authenticating a bit stream, characterized in that: The method comprises: Obtaining a first authentication identifier for each data unit in a set of data units from a bit stream; Determine first summary data of each data unit in the set of data units; the first summary data corresponds to the first authentication identifier; Acquire authentication data from the bit stream, the authentication data comprising: signature data, a second authentication identifier of each data unit in the set of data units, and second summary data of each data unit in the set of data units, the signature data being signed according to the second summary data of each data unit in the set of data units; Determining that the signature data verification is successful; In response to the plurality of first authentication identifiers of the group of data units being respectively identical to the plurality of second authentication identifiers in the authentication data, the plurality of first summary data of the group of data units are verified according to the plurality of second summary data in the authentication data.

26. The method according to claim 25, characterized in that The determining of the first summary data of each data unit in the group of data units comprises: Each data unit in the group of data units is calculated according to a digest algorithm to obtain first digest data of each data unit in the group of data units.

27. The method according to claim 26, characterized in that The digest algorithm is a digest algorithm indicated by a hash type hash_type, and the hash_type is parsed from a security parameter set RBSP of the bitstream.

28. The method according to any one of claims 25 to 27, characterized in that The method further comprises: The second summary data of each data unit in the group of data units is concatenated to determine summary data of the concatenated second summary data.

29. The method according to claim 28, characterized in that The method further comprises: The signature data is verified according to the summary data of the concatenated second summary data.

30. The method according to any one of claims 25 to 28, characterized in that The authentication data includes a summary data list, which is composed of second summary data of each data unit in the group of data units.

31. The method according to any one of claims 25 to 30, characterized in that The method further comprises: Acquire a first identifier from the bit stream, the first identifier indicating an authentication mode adopted by the group of data units; When the value of the first identifier is a first preset value, the step of determining the first summary data of each data unit in the group of data units is performed.

32. The method according to claim 31, characterized in that The bitstream further includes a security parameter set, and the security parameter set includes the first identifier.

33. The method according to any one of claims 25 to 32, characterized in that The method further comprises: Obtaining a fourth identifier from the bit stream, and determining a value n according to the fourth identifier; wherein the group of data units includes n data units, and n is a positive integer; Second summary data of each of the n data units is obtained from the bit stream.

34. The method according to any one of claims 25 to 33, characterized in that Each data unit in the set of data units includes one or more network abstraction layer NAL units.

35. The method according to claim 34, characterized in that The NAL unit includes an authentication enable flag authentication_idc, and the authentication_idc is used to indicate whether the NAL unit supports authentication.

36. The method according to claim 34 or 35, characterized in that Each NAL unit includes a second authentication identifier of the data unit to which it belongs.

37. The method according to any one of claims 25 to 36, characterized in that The bit stream further includes a NAL unit of authentication data, and the NAL unit of authentication data includes a second identifier; wherein the second identifier is temporal_id, which is used to indicate a temporal domain layer, and the value of the temporal_id is 0.

38. The method according to any one of claims 25 to 36, characterized in that The bit stream further includes a NAL unit of authentication data, and the NAL unit of authentication data includes a third identifier; wherein the third identifier is layer_id, which is used to indicate a spatial domain layer, and the value of layer_id is 0.

39. The method according to any one of claims 25 to 38, characterized in that The verifying the plurality of first summary data of the group of data units according to the plurality of second summary data in the authentication data comprises: For the first data unit in the group of data units; if second summary data identical to the first summary data of the first data unit is found among the multiple second summary data in the 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 has failed.

40. A code stream signature device, characterized in that: The method comprises a module for executing the bit stream signing method as claimed in any one of claims 1 to 14.

41. A code stream authentication device, characterized in that: The method comprises a module for executing a method for authenticating a bit stream as claimed in any one of claims 25 to 39.

42. An electronic device, characterized in that: include: a memory and a processor, the memory being coupled to the processor; The memory stores program instructions, which, when executed by the processor, enable the electronic device to execute a bit stream signing method as described in any one of claims 1 to 14, or to execute a bit stream authentication method as described in any one of claims 25 to 39.

43. 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 14, or executes the method according to any one of claims 25 to 39.

44. 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 14 are executed, or the steps of the method according to any one of claims 25 to 39 are executed.

45. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a bit stream according to any one of claims 15 to 24.

Images