Signing and authentication methods for bitstream

Abstract

Provided in the embodiments of the present application are signing and authentication methods for a bitstream. The signing method comprises: first, acquiring authentication data, wherein the authentication data comprises: signature data, and digest data of each data unit among a set of data units of a bitstream, the signature data being obtained by means of performing signing on the basis of the digest data of each data unit among the set of data units, and the data units among the set of data units being arranged in a first preset order; and then, adding the authentication data into the bitstream. In this way, data units may be individually authenticated at an authentication end, and thus, when some data units are lost (frame loss occurs), the other data units may also be authenticated. In addition, the order of the data units may also be verified, and repeated data units may be identified.

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 December 5, 2023, with application number 202311665406.7 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 will fail. For another example, each NAL unit or NAL unit sequence cannot be authenticated individually. 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 authentication very complicated and difficult to implement using existing technologies. Summary of the Invention

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

[0006] In a first aspect, an embodiment of the present application provides a method for signing a code stream, the method comprising: first, obtaining authentication data; wherein the authentication data comprises: signature data and summary data of each data unit in a group of data units in the code stream, the signature data being signed based on the summary data of each data unit in the group of data units, the summary data of each data unit in the group of data units being arranged in a first preset order; then, adding the authentication data to the code stream.

[0007] That is to say, this application makes an independent summary for each data unit and transmits the summary data of each data unit to the authentication end; in this way, the authentication end can authenticate each data unit independently; therefore, in the case that some data units are lost (frame loss), other data units can also be authenticated.

[0008] 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.

[0009] 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.

[0010] 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.

[0011] 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.

[0012] 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.

[0013] Again, the first preset order can be used by the authentication end to verify the order of the data units and to identify repeated data units, thereby further improving security.

[0014] Exemplarily, the first preset order may be pre-set by the signing end, or may be set by the signing end in real time during the encoding process.

[0015] It should be noted that the first preset order may be the decoding order of each data unit in a group of data units, or the arrangement order of each data unit in a group of data units in the code stream; this application does not impose any limitation on this.

[0016] data unit

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

[0018] NAL unit

[0019] 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.

[0020] access unit access unit

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

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

[0023] coded picture

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

[0025] 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.

[0026] For example, a group of data units may include n data units, each of which requires authentication, where n is a positive integer. Accordingly, the authentication data may include n digest data, each of which corresponds one-to-one to the n data units. For example, "a group of data units" may also be described as "n data units."

[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, summary data of each data unit in a group of data units, and the first preset order.

[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. In this way, bitrate overhead can be reduced.

[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] According to the first aspect, or any implementation of the first aspect above, the multiple NAL units of each data unit in a group of data units are associated with each other according to a specified rule, and the decoding order of the multiple NAL units of each data unit in the group of data units is continuous. In other words, one data unit is one access unit.

[0048] 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.

[0049] 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.

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

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

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

[0053] 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.

[0054] 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).

[0055] In one possible manner, the security parameter set in the code stream is represented in the form of an RBSP. Therefore, the code stream also includes a security parameter set, and the security parameter set includes a first identifier, which can be written as the code stream also includes a security parameter set RBSP, and the security parameter set RBSP includes the first identifier.

[0056] According to the first aspect, or any implementation of the first aspect above, the authentication data further includes: a second identifier, and the second identifier is used to identify a data unit.

[0057] Exemplarily, the second identifier may be decode_order_index.

[0058] Exemplarily, the authentication data may include multiple second identifiers, and the multiple second identifiers correspond one-to-one to the multiple data units.

[0059] Illustratively, compared with the prior art, the authentication data is newly added with decode_order_index.

[0060] 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 fourth identifier; wherein the fourth identifier indicates a time domain layer, and the value of the fourth identifier is 0.

[0061] Since in the time domain SVC coding scenario of the SVAC standard, the time domain basic layer (i.e., the data unit with the fourth 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 fourth identifier in the NAL unit of the authentication data can be set to 0.

[0062] 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 the fourth 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 fourth identifier.

[0063] Exemplarily, the fourth identifier may be temporal_id.

[0064] Exemplarily, compared with the prior art, authentication data is newly added with authentication_hash (digest data).

[0065] 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 fifth identifier; wherein the fifth identifier indicates the spatial level or the quality coding level, and the value of the fifth identifier is 0.

[0066] Since the spatial base layer / quality coding base layer (i.e., the data unit with the fifth 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 fifth identifier in the NAL unit of the authentication data can be set to 0.

[0067] Exemplarily, the fifth identifier may be layer_id.

[0068] 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 a private key. Exemplarily, the public key is a public key. The public key 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.

[0069] 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.

[0070] According to the first aspect, or any implementation of the first aspect above, the code stream further includes: a sixth identifier; the method further includes: determining a value n based on the sixth identifier; wherein a group of data units includes n data units, and n is a positive integer; and calculating each of the n data units according to the digest algorithm to obtain digest data of each of the n data units.

[0071] Exemplarily, the sixth identifier may be successive_hash_pictures_minus1.

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

[0073] According to a second aspect, each data unit in a group of data units includes one or more Network Abstraction Layer (NAL) units.

[0074] According to the second aspect, or any implementation of the second aspect above, the multiple NAL units of each data unit in a group of data units are associated with each other according to a specified rule, and the decoding order of the multiple NAL units of each data unit in a group of data units is continuous. That is, one data unit is an access unit

[0075] 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.

[0076] 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.

[0077] 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.

[0078] According to the second aspect, or any implementation of the second aspect above, the authentication data further includes: a second identifier, and the second identifier is used to identify a data unit.

[0079] 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 fourth identifier; wherein the fourth identifier indicates a time domain layer, and the value of the fourth identifier is 0.

[0080] 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 fifth identifier; wherein the fifth identifier indicates the spatial level or the quality coding level, and the value of the fifth identifier is 0.

[0081] According to the second aspect, or any implementation of the second aspect above, the code stream further includes: a sixth identifier, and the sixth identifier is used to determine the number n of data units included in a group of data units.

[0082] 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 seventh identifier, and the seventh identifier is used to determine the amount of summary data included in the authentication data.

[0083] 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.

[0084] In a third aspect, an embodiment of the present application provides a method for authenticating a code stream, the method comprising: first, determining first digest data of each data unit in a group of data units of the code stream; then, obtaining authentication data from the code stream, the authentication data comprising: signature data and second digest data of each data unit in the group of data units, the signature data being obtained by signing based on the second digest data of each data unit in the group of data units, the second digest data of each data unit in the group of data units being arranged in a first preset order; thereafter, when the signature data is successfully verified, verifying multiple first digest data of the group of data units based on the multiple second digest data in the authentication data, the first preset order, and the second preset order.

[0085] In this way, the authentication end can independently authenticate each data unit; therefore, even if some data units are lost (frame loss), other data units can still be authenticated. In addition, this 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 authentication.

[0086] Again, in the process of verifying multiple first summary data in a group of data units, this application utilizes the second preset order (determined by the authentication end) and the first preset order (determined by the signature end); thereby, the order of the data units can be verified, and repeated data units can be identified, thereby further improving security.

[0087] It should be noted that the first summary data and the second summary data are used to distinguish the summary data calculated by the authentication end from the summary data obtained from the authentication data.

[0088] It should be noted that the second preset order refers to the verification order of each data unit in a group of data units; for example, the second preset order can be the decoding order of each data unit in a group of data units, or the arrangement order of each data unit in a group of data units in the code stream; this application does not impose any restrictions on this.

[0089] 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.

[0090] 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.

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

[0092] According to the third aspect, or any implementation of the third aspect above, the method further includes: obtaining a seventh identifier from the code stream, and determining a value n based on the seventh 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.

[0093] According to the third aspect, or any implementation of the third aspect above, the method further includes: obtaining a sixth identifier from the code stream, and determining a value n based on the sixth identifier; wherein a group of data units includes n data units, and n is a positive integer; and determining first summary data for each data unit in the group of data units in the code stream includes: calculating each data unit in the n data units according to a summary algorithm to obtain summary data for each data unit in the n data units.

[0094] According to the third aspect, or any implementation manner of the third aspect above, multiple first summary data of a group of data units are verified according to multiple second summary data in the authentication data, the first preset order, and the second preset order, including: verifying the first summary data of each data unit in the group of data units in turn according to the second preset order; wherein the verification process for the first summary data of the first data unit in the group of data units is as follows: obtaining a first position; wherein the first position is determined based on the position of the second summary data that is the same as the first summary data of the data unit that was successfully authenticated in the previous authentication, in the multiple second summary data of the authentication data; the position of the second summary data that is the same as the first summary data of the data unit that was successfully authenticated in the previous authentication, in the multiple second summary data of the authentication data is determined according to the first preset order; and the first summary data of the first data unit is verified based on the first position and the multiple second summary data in the authentication data.

[0095] Exemplarily, the position of the second digest data that is the same as the first digest data of the data unit successfully authenticated in the previous time, in the plurality of second digest data of the authentication data, may be referred to as the third position.

[0096] In one possible embodiment, the first position may be the same as the third position.

[0097] In one possible manner, the first position may be a position subsequent to the third position among multiple positions corresponding to multiple second digest data of the authentication data, wherein one second digest data corresponds to one position.

[0098] Exemplarily, the first data unit may be any data unit in a group of data units.

[0099] According to the third aspect, or any implementation of the third aspect above, the first summary data of the first data unit is verified based on the first position and multiple second summary data in the authentication data, including: when second summary data identical to the first summary data of the first data unit exists in the multiple second summary data of the authentication data, determining the second position according to a first preset order; wherein the second position refers to the position of the second summary data identical to the first summary data of the first data unit in the multiple second summary data of the authentication data; determining whether the second position is located after the first position; if the second position is located after the first position, determining that the authentication of the first data unit is successful; if the second summary data identical to the first summary data of the first data unit is not found in the multiple second summary data of the authentication data, or the second position is located before the first position, or the second position is the same as the first position, determining that the authentication of the first data unit has failed. This corresponds to the situation where the first position is the same as the third position.

[0100] That is, in the process of authenticating the first summary data of a data unit, the present application not only considers whether there is second summary data identical to the first summary data of each data unit in the authentication data, but also considers whether the order of the second summary data identical to the first summary data of each data unit found in the authentication data (that is, the second preset order of each data unit) is the same as the first preset order. It can be seen that in the process of verifying the summary data of each data unit in a group of data units, the present application can also verify the order of the data units and identify duplicate data units, thereby further improving security.

[0101] Exemplarily, for the case where the first position is a position after the third position among multiple positions corresponding to multiple second digest data of the authentication data, the first digest data of the first data unit is verified based on the first position and the multiple second digest data in the authentication data, including: when second digest data identical to the first digest data of the first data unit exists in the multiple second digest data of the authentication data, determining the second position according to a first preset order; wherein the second position refers to the position of the second digest data identical to the first digest data of the first data unit in the multiple second digest data of the authentication data; judging whether the second position is before the first position; if the second position is after the first position, or the second position is the same as the first position, determining that the authentication of the first data unit is successful; if the second digest data identical to the first digest data of the first data unit is not found in the multiple second digest data of the authentication data, or the second position is before the first position, determining that the authentication of the first data unit has failed.

[0102] According to the third aspect, or any implementation manner of the third aspect above, the authentication data also includes multiple second identifiers, and the multiple second identifiers correspond one-to-one to the multiple second summary data. The method also includes: obtaining a third identifier corresponding to each data unit in a group of data units from the code stream; searching for a second identifier that is identical to the third identifier of the first data unit from the multiple second identifiers included in the authentication data; if there is a second identifier that is identical to the third identifier of the first data unit, comparing the first summary data of the first data unit and the second summary data corresponding to the second identifier that is identical to the third identifier of the first data unit; if the two are the same, determining that among the multiple second summary data of the authentication data, there is second summary data that is identical to the first summary data of the first data unit; otherwise, determining that among the multiple second summary data of the authentication data, there is no second summary data that is identical to the first summary data of the first data unit.

[0103] Exemplarily, the third identifier may be obtained from the picture header RBSP, and the third identifier may be decode_order_index.

[0104] According to the third aspect, or any implementation of the third aspect, the method includes searching for second digest data identical to first digest data of the first data unit from a plurality of second digests included in the authentication data.

[0105] According to the third aspect, or any implementation of the third aspect above, the first summary data of the first data unit is verified based on the first position and multiple second summary data in the authentication data, including: starting from the first position among the multiple positions corresponding to the multiple second summary data of the authentication data, searching backward; if second summary data identical to the first summary data of the first data unit is found, 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.

[0106] Exemplarily, starting from the first position among the multiple positions corresponding to the multiple second summary data of the authentication data, searching backward for the searched position may include the first position or may not include the first position; this application does not impose any limitation on this.

[0107] In this implementation, the order of data units can be verified, thereby further improving security.

[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 above, multiple NAL units of each data unit in a group of data units are associated with each other according to a specified rule, and the decoding order of multiple NAL units of each data unit 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] It should be noted that the authentication process involved in this application may include verification of signature data and verification of summary data (ie, first summary data) of the data unit (or verification of the data unit).

[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 code stream signature device, the device comprising:

[0115] a first authentication data acquisition module, configured to acquire authentication data; wherein the authentication data includes signature data and summary data of each data unit in a group of data units in the code stream, wherein the signature data is obtained by signing the summary data of each data unit in the group of data units, and the summary data of each data unit in the group of data units is arranged in a first preset order;

[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] a summary data determination module, configured to determine first summary data of each data unit in a group of data units of a code stream;

[0121] a second authentication data acquisition module, configured to acquire authentication data from the code stream, the authentication data comprising: signature data and second digest data of each data unit in a group of data units, the signature data being signed based on the second digest data of each data unit in the group of data units, the second digest data of each data unit in the group of data units being arranged in a first preset order;

[0122] The verification module is configured to verify the plurality of first summary data of a group of data units according to the plurality of second summary data in the authentication data, the first preset sequence and the second preset sequence when the signature data is successfully verified.

[0123] 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.

[0124] 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.

[0125] 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.

[0126] 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.

[0127] 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.

[0128] 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.

[0129] 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.

[0130] 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.

[0131] 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.

[0132] 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.

[0133] 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.

[0134] 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.

[0135] 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.

[0136] 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.

[0137] 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.

[0138] 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.

[0139] 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.

[0140] 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.

[0141] 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.

[0142] 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.

[0143] 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.

[0144] 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.

[0145] 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.

[0146] 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.

[0147] 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.

[0148] 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.

[0149] In an eighteenth aspect, an embodiment of the present application provides a method for authenticating a code stream, the method comprising: first, determining first digest data of each data unit in a group of data units of the code stream; and obtaining authentication data from the code stream, the authentication data comprising signature data and second digest data of each data unit in the group of data units, the signature data being signed based on the second digest data of each data unit in the group of data units; then, when the signature data is successfully verified, if second digest data identical to the first digest data of the data unit being verified is found from multiple second digest data of the authentication data, then determining that the second digest data identical to the first digest data of the data unit being verified is the same as the first digest data of the data unit being verified. whether the second digest data that is identical to the first digest data of the verified data unit is the same; if the second digest data that is identical to the first digest data of the data unit being verified is not found from the multiple second digest data of the authentication data, or the second digest data that is identical to the first digest data of the data unit being verified is the same as the second digest data that is identical to the first digest data of the verified data unit, it is determined that the authentication of the data unit being verified has failed; if the second digest data that is identical to the first digest data of the data unit being verified is different from the second digest data that is identical to the first digest data of the verified data unit, it is determined that the authentication of the data unit being verified is successful.

[0150] In this way, the authentication end can independently authenticate each data unit; therefore, even if some data units are lost (frame loss), other data units can still be authenticated. In addition, this 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 authentication.

[0151] Thirdly, repeated data units are identified by determining whether the first digest data of the plurality of data units are identical to the same second digest data in the authentication data.

[0152] Exemplarily, the verified data unit may refer to all verified data units (which may also be referred to as successfully authenticated data units); the verified data unit may be one or more.

[0153] According to the eighteenth aspect, each second summary data has a corresponding preset identifier; judging whether the second summary data identical to the first summary data of the data unit to be verified this time is identical to the second summary data of the first summary data of the data unit to be verified this time, includes: judging whether the value of the preset identifier corresponding to the second summary data identical to the first summary data of the data unit to be verified this time is a second preset value; when the value of the preset identifier corresponding to the second summary data identical to the first summary data of the data unit to be verified this time is the second preset value, determining that the second summary data identical to the first summary data of the data unit to be verified this time is different from the second summary data identical to the first summary data of the data unit to be verified this time; and setting the value of the preset identifier corresponding to the second summary data identical to the first summary data of the data unit to be verified this time to a third preset value; otherwise, determining that the second summary data identical to the first summary data of the data unit to be verified this time is identical to the second summary data identical to the first summary data of the data unit to be verified.

[0154] Exemplarily, the second preset value can be set as required, for example, 0; this application does not impose any limitation on this.

[0155] For example, the third preset value can be set as required, for example, 1; this application does not limit this. The second preset value is different from the third predicted value. BRIEF DESCRIPTION OF THE DRAWINGS

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

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

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

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

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

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

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

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

[0164] FIG7 is a schematic diagram of an exemplary code stream signature device;

[0165] FIG8 is a schematic diagram of an illustrative device for authenticating a code stream;

[0166] FIG9 is a schematic structural diagram of an exemplary device. DETAILED DESCRIPTION

[0167] 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.

[0168] 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.

[0169] 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.

[0170] 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.

[0171] 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.

[0172] FIG1 shows a schematic diagram of the structure of an electronic device 100. It should be understood that the electronic device 100 shown in FIG1 is merely an example of an electronic device, and that the electronic device 100 may have more or fewer components than shown, may combine two or more components, or may have a different component configuration. The various components shown in FIG1 may be implemented in hardware, including one or more signal processing and / or application-specific integrated circuits, software, or a combination of hardware and software.

[0173] 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.

[0174] bitstream

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

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

[0177] 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.

[0178] 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.

[0179] 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.

[0180] 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.

[0181] 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 .

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

[0183] 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 .

[0184] 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.

[0185] 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 .

[0186] 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 .

[0187] 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 .

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

[0189] 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.

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

[0191] 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 .

[0192] 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 .

[0193] For example, the authentication result 205 may be the authentication result 105 , the authentication result 107 , or the authentication result 109 in the above-mentioned image 1 .

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

[0195] 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.

[0196] 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.

[0197] 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.

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

[0199] S301, obtaining authentication data; wherein the authentication data includes: signature data and summary data of each data unit in a group of data units, the signature data is obtained by signing based on the summary data of each data unit in a group of data units, and the summary data of each data unit in a group of data units is arranged according to a first preset order.

[0200] For example, when authentication needs to be supported, the number n of data units that need to be authenticated may be determined, where n is a positive integer.

[0201] data unit

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

[0203] NAL unit

[0204] 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.

[0205] access unit access unit

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

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

[0208] coded picture

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

[0210] 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.

[0211] 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.

[0212] 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.

[0213] 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).

[0214] Exemplarily, authentication data (Auth) may be generated according to the signature data, summary data of each data unit in a group of data units, and a first preset order.

[0215] For example, the signing end may pre-set a first preset order; then, during the process of generating the authentication data, the summary data of each data unit in a group of data units may be arranged according to the first preset order (the first preset order may also be generated in real time). In other words, the summary data of each data unit in a group of data units in the authentication data is arranged according to the first preset order.

[0216] It should be noted that the first preset order may be the decoding order of each data unit in a group of data units, or the arrangement order of each data unit in a group of data units in the code stream; this application does not impose any limitation on this.

[0217] For example, the decoding order of n data units is: data unit 1, data unit 2, data unit 3, ..., data unit n, and the authentication data can be {digest data 1, digest data 2, ..., digest data n, signature}.

[0218] For example, the decoding order of n data units is: data unit n, data unit n-1, data unit n-2, ..., data unit 1, then the authentication data can be {digest data n, digest data n-1, ..., digest data 1, signature}.

[0219] Optionally, the summary data of each data unit in a group of data units in the authentication data may form a summary data list {summary data 1, summary data 2, ..., summary data n}. In other words, the summary data of each data unit in a group of data units in the summary data list are also arranged according to the first preset order.

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

[0221] 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 .

[0222] 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.

[0223] 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 .

[0224] S401: Determine first summary data of each data unit in a group of data units.

[0225] 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 S401 from the digest data included in the authentication data, the digest data calculated in S401 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.

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

[0227] 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.

[0228] S402, obtaining authentication data from the code stream, the authentication data including: signature data and second summary data of each data unit in a group of data units, the signature data being signed based on the second summary data of each data unit in the group of data units, the second summary data of each data unit in the group of data units being arranged in a first preset order.

[0229] Exemplarily, the code stream may be parsed to read authentication data from the code stream, wherein the authentication data includes signature data and n second digest data (including digest data 21, digest data 22, ..., digest data 2n).

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

[0231] 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.

[0232] Illustratively, the second summary data of each data unit in a group of data units in the authentication data obtained by the authenticator from the code stream is arranged in a first preset order.

[0233] S403 : When the signature data is successfully verified, verify the plurality of first digest data of a group of data units according to the plurality of second digest data in the authentication data, the first preset order, and the second preset order.

[0234] Exemplarily, the signature data may be verified. When the signature data is successfully verified, the plurality of first digest data of a group of data units are verified according to the plurality of second digest data in the authentication data, the first preset order, and the second preset order.

[0235] Among them, the second preset order may refer to the verification order of each data unit in a group of data units, which is determined by the authentication end; for example, the second preset order may be the decoding order of each data unit in a group of data units, or the arrangement order of each data unit in a group of data units in the code stream; this application does not impose any restrictions on this.

[0236] Specifically, the first summary data of each data unit in a group of data units can be verified in sequence according to the second preset order; wherein, the verification process for the first summary data of the first data unit in a group of data units is as follows: first, obtain the first position; wherein, the first position is determined based on the position of the second summary data that is identical to the first summary data of the data unit that was successfully authenticated in the previous time, in the multiple second summary data of the authentication data (hereinafter referred to as the third position); the position of the second summary data that is identical to the first summary data of the data unit that was successfully authenticated in the previous time, in the multiple second summary data of the authentication data is determined according to the first preset order.

[0237] In one possible embodiment, the first position may be the same as the third position.

[0238] In a possible manner, the first position may be a position subsequent to the third position among multiple positions corresponding to multiple second digest data of the authentication data.

[0239] Next, the first summary data of the first data unit is verified according to the first position and the plurality of second summary data in the authentication data; details will be described in subsequent embodiments.

[0240] It should be noted that S401 to S403 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 authentication module executes S401 and S403, and the decoder block executes S402). This application does not impose any restrictions on this.

[0241] 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.

[0242] 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.

[0243] 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.

[0244] 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.

[0245] 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.

[0246] Secondly, since each data unit is authenticated independently, even if some data units are lost (frame loss), other data units can still be authenticated.

[0247] In addition, in the process of verifying multiple first summary data in a group of data units, the present application utilizes the second preset order (determined by the authentication end) and the first preset order (determined by the signature end); thereby, the order of the data units can be verified, and repeated data units can be identified, thereby further improving security.

[0248] 5A is a schematic diagram illustrating an exemplary signing process 500. The process 500 may be implemented by the signing terminal 210. The process 500 is a process in which the SVAC signing terminal uses SuccessiveHashPictures to indicate the end of the data unit authentication sequence to implement data unit signing.

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

[0250] 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 1 below:

[0251] Table 1 Security Parameter Set RBSP Definition

[0252] authentication_mode

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

[0254] Table 2 Authentication mode description

[0255] 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.

[0256] Number of consecutive authentication image frames successive_hash_pictures_minus1

[0257] 8-bit unsigned integer. Indicates the number of consecutive displayed pictures (or data units) that are digitally signed in decoding order, and these consecutive displayed pictures (or data units) are limited to one random access picture or RLI frame picture interval. The value of successive_hash_pictures_minus1 should be 0 to 255.

[0258] SuccessiveHashPictures=successive_hash_pictures_minus1+1

[0259] If successive_hash_pictures_minus1 is equal to 0, the digest data of each display image (or data unit) to be authenticated is digitally signed.

[0260] If successive_hash_pictures_minus1 is greater than 0 and authenticate_mode is 0, first concatenate the summary data of SuccessiveHashPictures image data (or data units), perform summary data on the concatenated summary data, and then digitally sign the summary data.

[0261] If successive_hash_pictures_minus1 is greater than 0 and authenticate_mode is 1, a tree-type digest is first generated for the digest data of SuccessiveHashPictures consecutive display images (or data units) in decoding order, and then the tree-top digest is digitally signed (i.e., the conventional signature method). The tree-top digest of n data units is the digest data of the tree-top digests of the first n-1 data units and the digest data of the nth data unit, which are arranged and generated according to the digest algorithm (such as the authentication method indicated by hash_type).

[0262] Hash type hash_type

[0263] 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:

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

[0265] Digital signature type signature_type

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

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

[0268] Authentication enable flag authentication_flag

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

[0270] Table 5 Description of authentication enable flags

[0271] 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.

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

[0273] 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.

[0274] 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.

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

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

[0277] Exemplarily, the number of data units that need to be authenticated, SuccessiveHashPictures, can be calculated based on successive_hash_pictures_minus1 (also called the sixth identifier) ​​in the security parameter set RBSP; that is, the number of data units included in a group of data units is SuccessiveHashPictures.

[0278] Wherein, SuccessiveHashPictures=successive_hash_pictures_minus1+1. Then, each data unit in the SuccessiveHashPictures data units with authentication_idc being 1 can be calculated according to the digest algorithm to obtain digest data of each data unit in the SuccessiveHashPictures data units.

[0279] In one possible approach, authentication_idc is located in the NAL header of the NAL unit.

[0280] Authentication enable flag authentication_idc

[0281] 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.

[0282] 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 the SuccessiveHashPictures data units whose authentication_idc is 1 according to the authentication algorithm indicated by hash_type in the security parameter set RBSP, to obtain the digest data of each data unit in the SuccessiveHashPictures data units. For example, a hash calculation may be performed on each data unit in the SuccessiveHashPictures data units whose authentication_idc is 1 according to the digest algorithm indicated by hash_type in the security parameter set RBSP, to obtain the digest data of each data unit in the SuccessiveHashPictures data units.

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

[0284] 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.

[0285] 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 5 to obtain summary data H5; ...; a hash calculation is performed on data unit n to obtain summary data Hn.

[0286] S503: Concatenate summary data of each data unit in a group of data units to determine summary data of the concatenated summary data.

[0287] Illustratively, the summary data of each data unit in the SuccessiveHashPictures data units whose authentication_idc is 1 may be concatenated to obtain the concatenated summary data H1+H2+H3+H4+H5+...+Hn.

[0288] 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 ).

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

[0290] 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.

[0291] 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.

[0292] 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.

[0293] 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.

[0294] Exemplarily, authentication data is generated according to the summary data, signature data and the first preset order of each data unit in a group of data units.

[0295] For example, the first preset order of n data units is: data unit 1, data unit 2, data unit 3, data unit 4, data unit 5,..., data unit n, then the authentication data may include {H1, H2, H3, H4, H5,..., Hn, signature}.

[0296] S505 , encoding the authentication data, and adding the encoded authentication data to the code stream; wherein the summary data of each data unit in a group of data units of the authentication data is arranged according to a first preset order.

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

[0298] In one possible approach, when the data unit includes one or more access units, or the data unit is a coded picture, the authentication data RBSP definition in the NAL unit of the authentication data may be as shown in Table 6 below:

[0299] Table 6 Authentication data RBSP definition

[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 data includes summary data, namely, authentication_hash (authentication summary data) in Table 6.

[0309] Exemplarily, authentication_hash_number_minus1 in the authentication data RBSP may be referred to as the seventh identifier.

[0310] It should be noted that, compared with the authentication data RBSP in the prior art, the NAL unit of the authentication data in Table 6 of the present application newly adds authentication_hash and authentication_hash_number_minus1.

[0311] In one possible approach, when the data unit includes multiple access units, or the data unit is a coded picture, the authentication data RBSP definition in the NAL unit of the authentication data may be as shown in Table 7 below:

[0312] Table 7 Authentication data RBSP definition

[0313] Decoding order index decode_order_index

[0314] 8-bit unsigned integer. Indicates the decoding order index value of the current picture. Same as the definition of decode_order_index in the picture header RBSP.

[0315] For example, the definitions of other syntax elements in Table 7 can refer to the description of Table 6 and will not be repeated here.

[0316] It should be noted that, compared with the authentication data RBSP in the prior art, the NAL unit of the authentication data in Table 7 of the present application is newly added with authentication_hash, authentication_hash_number_minus1 and decode_order_index (also referred to as the second identifier).

[0317] In addition, in the time-domain SVC coding scenario of the SVAC standard, each data unit includes a fourth identifier (temporal_id) for identifying the time-domain layer of the data unit; correspondingly, the authentication data RBSP may also include the fourth identifier (temporal_id). Since the time-domain base layer (i.e., the data unit with the fourth 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 fourth identifier in the NAL unit of the authentication data can be set to 0.

[0318] In the SVAC standard's spatial SVC coding or quality SVC coding scenario, each data unit includes a fifth 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 fifth identifier (layer_id). Since the spatial base layer / quality coding base layer (i.e., the data unit with the fifth 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 fifth identifier in the NAL unit of the authentication data may be set to 0.

[0319] Exemplarily, the authentication data may include multiple second identifiers, and the multiple second identifiers correspond one-to-one to the multiple data units. Exemplarily, the multiple second identifiers may form a decoding order list, that is, the authentication data may include the decoding order list.

[0320] 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.

[0321] 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.

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

[0323] 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.

[0324] 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 FIG5B for the first group of data units and the authentication data of the first group of data units. 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 FIG5B for the second group of data units and the authentication data of the second group of data units). This is due to the difference between the rate of encoding data units and the rate of generating authentication data. However, since each data unit is independently authenticated in this application, it will not affect the authentication of the current group of data units.

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

[0326] 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 SuccessiveHashPictures indicates the end of the data unit authentication sequence. Process 600 corresponds to process 500.

[0327] S601 : Calculate each data unit in a group of data units of a code stream according to a digest algorithm to obtain first digest data of each data unit in the group of data units.

[0328] 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.

[0329] 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.

[0330] 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.

[0331] 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.

[0332] For example, the successive_hash_pictures_minus1 in the security parameter set RBSP is parsed; based on the value of the parsed successive_hash_pictures_minus1 (also referred to as the sixth identifier), SuccessiveHashPictures is calculated. Furthermore, it can be determined that SuccessiveHashPictures data units need to be authenticated; that is, the number of data units contained in a group of data units is SuccessiveHashPictures. Where SuccessiveHashPictures = successive_hash_pictures_minus1 + 1.

[0333] 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.

[0334] For example, after receiving the security parameter set RBSP of the codestream, the authenticator 220 may receive a NAL unit. At this point, the authenticator 220 may parse the NAL unit and extract the authentication_idc from the NAL unit header. Upon receiving each of the SuccessiveHashPictures data units where the authentication_idc is 1, the authenticator 220 may perform calculations on each data unit to obtain digest data for each of the SuccessiveHashPictures data units.

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

[0336] For example, a hash calculation may be performed on each of the SuccessiveHashPictures data units with authentication_idc being 1 according to the digest algorithm indicated by hash_type in the security parameter set RBSP to obtain the digest data of each of the SuccessiveHashPictures data units with authentication_idc being 1.

[0337] In one possible approach, when hash_type is not parsed from the security parameter set RBSP of the code stream, each data unit in the SuccessiveHashPictures data units with authentication_idc being 1 can be calculated according to a pre-agreed digest algorithm to obtain summary data of each data unit in the SuccessiveHashPictures data units with authentication_idc being 1.

[0338] 6A , n first summary data are {H1′, H2′, H3′, H4′, H5′, . . . , Hn′}

[0339] S602. Obtain authentication data from the code stream. The authentication data includes signature data and second summary data of each data unit in a group of data units. The signature data is obtained by signing the second summary data of each data unit in the group of data units. The second summary data of each data unit in the group of data units is arranged in a first preset order.

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

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

[0342] Exemplarily, the authentication_hash in the authentication data RBSP is parsed according to authentication_hash_number_minus1 to obtain the second summary data of each data unit in SuccessiveHashPictures data units with authentication_idc being 1; wherein the number of the second summary data is the same as the value calculated according to authentication_hash_number_minus1.

[0343] 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.

[0344] Exemplarily, when the authentication data RBSP is defined as shown in Table 6, the authentication data may include {H1, H2, H3, H4, H5, ..., Hn, signature}.

[0345] For example, when the authentication data RBSP is defined as shown in Table 7, the authentication data may include {decode_order_index_1, decode_order_index_2, decode_order_index_3, decode_order_index_4, decode_order_index_5, ..., decode_order_index_n, H1, H2, H3, H4, H5, ..., Hn, signature}, where decode_order_index_1 corresponds to H1, decode_order_index_2 corresponds to H2, and so on.

[0346] S603: Verify the signature data according to the public key, the second summary data of each data unit in a group of data units, and the signature algorithm.

[0347] For example, the second digest data of each data unit in the SuccessiveHashPictures data units with an authentication_idc of 1 can be concatenated to obtain the concatenated second digest data. Next, the digest data Hg' of the concatenated second digest data is determined. Subsequently, a signature verification algorithm corresponding to the signature algorithm can be used to process the public key, Hg', and the signature data to obtain a verification result for the signature data.

[0348] 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.

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

[0350] 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.

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

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

[0353] S604: When the signature data is successfully verified, the first summary data of each data unit in a group of data units is verified in sequence according to a second preset order.

[0354] Exemplarily, the verification process for the first summary data of the first data unit in a group of data units is as described below in S6041 to S6042:

[0355] The first data unit may be any data unit in a group of data units.

[0356] S6041, obtaining a first position; wherein the first position is determined based on the position of the second summary data identical to the first summary data of the data unit that was successfully authenticated previously, in the multiple second summary data of the authentication data; the position of the second summary data identical to the first summary data of the data unit that was successfully authenticated previously, in the multiple second summary data of the authentication data, is determined based on a first preset order.

[0357] The position of the second digest data that is the same as the first digest data of the data unit successfully authenticated in the previous time in the multiple second digest data of the authentication data can be called the third position.

[0358] In one possible embodiment, the first position may be the same as the third position.

[0359] In a possible manner, the first position may be a position subsequent to the third position among multiple positions corresponding to multiple second digest data of the authentication data.

[0360] For example, the authentication data is {digest data 21, digest data 22, ..., digest data 2n, signature}; it is assumed that the positions of "digest data 21, digest data 22, ..., digest data 2n" in the authentication data are represented by 1, 2, 3, ..., n respectively.

[0361] When the second digest data in the authentication data that is the same as the first digest data of the data unit successfully authenticated in the previous time is digest data 21, the third position is "1"; at this time, the first position can be "1" or "2".

[0362] When the second digest data in the authentication data that is the same as the first digest data of the data unit successfully authenticated in the previous authentication is digest data 22, the third position is "2"; in this case, the first position can be "2" or "3".

[0363] And so on, I will not go into details here.

[0364] S6042: Verify the first summary data of the first data unit according to the first position and the plurality of second summary data in the authentication data.

[0365] Exemplarily, in a possible implementation of S6042, when the first position is the same as the third position, when there is second summary data identical to the first summary data of the first data unit among the multiple second summary data of the authentication data, the second position is determined according to the first preset order, and the second position refers to the position of the second summary data identical to the first summary data of the first data unit in the multiple second summary data of the authentication data; it is determined whether the second position is after the first position; if the second position is after the first position, it is determined that the authentication of the first data unit is successful; if the second summary data identical to the first summary data of the first data unit is not found in the multiple second summary data of the authentication data, or the second position is before the first position, or the second position is the same as the first position, it is determined that the authentication of the first data unit has failed.

[0366] Exemplarily, in a possible implementation of S6042, in a case where the first position is a position after the third position in multiple positions corresponding to multiple second summary data of the authentication data, when there is second summary data identical to the first summary data of the first data unit in the multiple second summary data of the authentication data, the second position is determined according to a first preset order, the second position refers to the position of the second summary data identical to the first summary data of the first data unit in the multiple second summary data of the authentication data; it is determined whether the second position is before the first position; if the second position is after the first position or the second position is the same as the first position, it is determined that the authentication of the first data unit is successful; if the second summary data identical to the first summary data of the first data unit is not found in the multiple second summary data of the authentication data, or the second position is before the first position, it is determined that the authentication of the first data unit has failed.

[0367] The following description will be given by taking the case where the first position and the third position are the same as an example.

[0368] For example, the authentication data is {digest data 21, digest data 22, ..., digest data 2n, signature}; it is assumed that the positions of "digest data 21, digest data 22, ..., digest data 2n" in the authentication data are represented by 1, 2, 3, ..., n respectively.

[0369] Assuming that the second digest data in the authentication data that is identical to the first digest data of the previously successfully authenticated data unit is digest data 22, the first position is "2." Furthermore, assuming that the second digest data in the authentication data that is identical to the first digest data of the first data unit is digest data 23, the second position is "3." In this case, it can be determined that the second position is after the first position. This indicates that the decoding order of the first data unit by the authenticator is the same as the decoding order set by the signer for the first data unit. In this case, it can be determined that the authentication of the first data unit is successful.

[0370] Assuming that the second digest data in the authentication data that is identical to the first digest data of the previously successfully authenticated data unit is digest data 24, the first position is "4." Furthermore, assuming that the second digest data in the authentication data that is identical to the first digest data of the first data unit is digest data 23, the second position is "3." In this case, it can be determined that the second position is before the first position. This indicates that the decoding order of the first data unit by the authenticator differs from the decoding order set by the signer for the first data unit. In other words, the order of the first data units is incorrect. In this case, it can be determined that the authentication of the first data unit has failed.

[0371] Assuming that the second digest data in the authentication data that is identical to the first digest data of the previously successfully authenticated data unit is digest data 22, the first position is "2." Furthermore, assuming that the second digest data in the authentication data that is identical to the first digest data of the first data unit is digest data 22, the second position is "2." In this case, it can be determined that the second position is identical to the first position. This indicates that the first data unit and the previously successfully authenticated data unit are duplicates, that is, the first data unit and the previously successfully authenticated data unit are the same data unit. In this case, it can be determined that authentication of the first data unit has failed.

[0372] Specifically, during the implementation process, a parameter P can be set to record the position of the second summary data that is the same as the first summary data of the data unit that has been successfully authenticated, in the multiple second summary data of the authentication data. The initial value of P can be set to 0. The positions of the multiple second summary data in the authentication data can be represented by 1, 2, 3, ..., n. Exemplarily, it can be determined whether the second position is located after the first position by judging whether the numerical value used to represent the second position is greater than the value of P. If the numerical value used to represent the second position is greater than the value of P, it is determined that the second position is located after the first position. If the numerical value used to represent the second position is less than or equal to the value of P, it is determined that the second position is located before the first position, or the second position is the same as the first position.

[0373] For example, if the initial value of P is 0 and the first data unit is the first decoded data unit in the group of data units, and if the second digest data in the authentication data that is identical to the first digest data of the first data unit is digest data 21, the second position can be represented by the value "1". Since the value "1" is greater than the value "0" of P, it can be determined that the authentication of the first data unit is successful. Then, P can be assigned a value of "1".

[0374] Next, when the first data unit is the second decoded data unit in the group of data units, if the second digest data in the authentication data that is the same as the first digest data of the first data unit is digest data 22, the second position can be represented by the value "2". Since the value "2" is greater than the value "1" of P, it can be determined that the authentication of the first data unit is successful. Then, P can be assigned the value "2".

[0375] Later, when the first data unit is the third decoded data unit in the group of data units, if the second digest data in the authentication data that is the same as the first digest data of the first data unit is digest data 21, the second position can be represented by the value "1". Since the value "1" is less than the value "2" of P, it can be determined that the authentication of the first data unit has failed. At this time, the value of P remains unchanged and remains 2.

[0376] Subsequently, when the first data unit is the fourth decoded data unit in the group of data units, if the second digest data in the authentication data that is the same as the first digest data of the first data unit is digest data 24, the second position can be represented by the value "4". Since the value "4" is greater than the value "2" of P, it can be determined that the authentication of the first data unit is successful. In this case, P can be assigned the value "4".

[0377] Then, when the first data unit is the fifth decoded data unit in the group of data units, if the second digest data in the authentication data that is the same as the first digest data of the first data unit is digest data 24, the second position can be represented by the value "4". Since the value "4" is equal to the value "4" of P, it can be determined that the authentication of the first data unit has failed. At this time, the value of P remains unchanged and remains 4.

[0378] And so on, I will not go into details here.

[0379] For example, during the implementation process, the summary data list {summary data 21, summary data 22, ..., summary data 2n} can be made into a Map data structure, where in the Map, the KEY uses the second summary data and the value is set to the position, such as Map[summary data 21] = 1, Map[summary data 22] = 1, ..., Map[summary data 2n] = 1, to achieve fast search.

[0380] Illustratively, there may be multiple ways to determine whether there is second digest data identical to the first digest data of the first data unit among the multiple second digest data of the authentication data, and this application does not impose any limitation thereto.

[0381] In one possible approach, when the authentication data RBSP is defined as shown in Table 6, for a first data unit in a group of data units, a summary data list {H1, H2, H3, H4, H5, ..., Hn} of the authentication data may be directly searched for summary data identical to the summary data Hk' of the first data unit (e.g., traversed); if summary data identical to the summary data Hk' of the first data unit is found, it is determined that summary data identical to the summary data Hk' of the first data unit exists in the summary data list {H1, H2, H3, H4, H5, ..., Hn} of the authentication data. If summary data identical to the summary data Hk' of the first data unit is not found, it is determined that summary data identical to the summary data Hk' of the first data unit does not exist in the summary data list {H1, H2, H3, H4, H5, ..., Hn} of the authentication data.

[0382] In one possible approach, when the authentication data RBSP is defined as shown in Table 7, for the first data unit in a group of data units, a decoding order index identical to the decoding order index decode_order_index_k of the first data unit can be searched from the decoding order list {decode_order_index_1, decode_order_index_2, decode_order_index_3, decode_order_index_4, decode_order_index_5, ..., decode_order_index_n} of the authentication data. If there exists a decode_order_index_j identical to decode_order_index_k, the digest data Hk' of the first data unit is compared with the digest data Hj corresponding to decode_order_index_j, where j is less than or equal to n. If Hk' and Hj are identical, it is determined that the digest data list {H1, H2, H3, H4, H5, ..., Hn} of the authentication data contains digest data identical to the digest data Hk' of the first data unit. If there is no decoding order index identical to decode_order_index_k, or Hk' and Hj are different, it is determined that there is no summary data identical to the summary data Hk' of the first data unit in the summary data list {H1, H2, H3, H4, H5, ..., Hn} of the authentication data.

[0383] Exemplarily, in a possible implementation of S6042, starting from the first position among the multiple positions corresponding to the multiple second summary data of the authentication data, search backward; if the second summary data that is identical to the first summary data of the first data unit is found, 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.

[0384] Wherein, starting from the first position among the multiple positions corresponding to the multiple second digest data of the authentication data, searching backward for the searched position may include or exclude the first position.

[0385] For example, the authentication data is {digest data 21, digest data 22, ..., digest data 2n, signature}; it is assumed that the positions of "digest data 21, digest data 22, ..., digest data 2n" in the authentication data are represented by 1, 2, 3, ..., n respectively.

[0386] In the case where the first position is the same as the third position, the position to be searched backward does not include the first position. If it is assumed that the second summary data in the authentication data that is the same as the first summary data of the data unit that was successfully authenticated previously is summary data 22, and the first position is "2", then the second summary data that is the same as the first summary data of the first data unit can be searched backward from {summary data 23, summary data 24, ..., summary data 2n}. If it is assumed that the second summary data in the authentication data that is the same as the first summary data of the data unit that was successfully authenticated previously is summary data 25, and the first position is "5", then the second summary data that is the same as the first summary data of the first data unit can be searched from {summary data 26, summary data 27, ..., summary data 2n}. And so on, which will not be repeated here.

[0387] In the case where the first position is a plurality of positions corresponding to a plurality of second summary data of the authentication data, and the position after the third position is searched backward, the position to be searched includes the first position. If it is assumed that the second summary data in the authentication data that is identical to the first summary data of the data unit that was successfully authenticated previously is summary data 22, and the first position is "3", then the second summary data that is identical to the first summary data of the first data unit can be searched from {summary data 23, summary data 24, ..., summary data 2n}. If it is assumed that the second summary data in the authentication data that is identical to the first summary data of the data unit that was successfully authenticated previously is summary data 25, and the first position is "6", then the second summary data that is identical to the first summary data of the first data unit can be searched from {summary data 26, summary data 27, ..., summary data 2n}. And so on, which will not be repeated here.

[0388] In one possible approach, the SVAC signing end can implement data unit signing by using the security parameter set RBSP to identify the end or start of a group of data units. Correspondingly, the SVAC authenticating end can implement data unit signing when the security parameter set RBSP identifies the end or start of a group of data units. In this case, the security parameter set RBSP definition can be shown in Table 8:

[0389] Table 8 Security Parameter Set RBSP Definition

[0390] Among them, the description of the syntax elements in Table 8 can refer to the description of the syntax elements in Table 1 above, and will not be repeated here.

[0391] For example, when video image authentication needs to be supported, a security parameter set RBSP is generated. It should be noted that the signing end 210 can indicate the end of the previous authentication sequence (i.e., the previous set of data units) by inserting a new security parameter set RBSP, stop authentication, or start a new authentication (authentication of the next set of data units).

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

[0393] Exemplarily, when the signature method of the present application is adopted, during the process of generating the security parameter set RBSP, authenticate_mode in the security parameter set RBSP may be set to 0.

[0394] 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.

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

[0396] In this way, the signing process of the codestream by the signing end 210 can refer to S501 to S505 described above. In the case where the security parameter set RBSP is as shown in Table 8, the method for determining the data units that require authentication in S502 is slightly different from the method described above. In the case where the security parameter set RBSP is as shown in Table 8, after generating a security parameter set RBSP, the signing end 210 independently calculates the summary data for each data unit where the authentication_idc in the NAL header is 1 until the next security parameter set RBSP is generated. In other words, the data units located between two security parameter set RBSPs are the data units that require authentication.

[0397] For example, the authentication process of the codestream by the authenticator 220 can refer to S601 to S604 described above. In the case where the security parameter set RBSP is as shown in Table 8, the method for determining the data unit to be authenticated in S601 is slightly different from the method described above. In the case where the security parameter set RBSP is as shown in Table 8, after receiving a security parameter set RBSP, the authenticator 220 can independently calculate the digest data for each subsequently received data unit with an authentication_idc value of 1 until the next security parameter set RBSP is received.

[0398] Exemplarily, when the security parameter set RBSP is defined as shown in Table 8, the authentication data RBSP may be defined as shown in Table 6 or Table 7, which will not be described in detail here.

[0399] For example, the embodiment of the present application further provides a code stream authentication method, which can identify repeated data units. The authentication process is as follows S1 to S5:

[0400] S1, determining first summary data of each data unit in a group of data units of a code stream.

[0401] For example, S1 may refer to the description of S601 above, which will not be repeated here.

[0402] S2. Acquire authentication data from the code stream. The authentication data includes signature data and second summary data of each data unit in a group of data units. The signature data is obtained by signing the second summary data of each data unit in the group of data units.

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

[0404] It should be noted that the second summary data of multiple data units of a group of data units included in the authentication data in S2 can be arranged in a first preset order, or in other orders or randomly; this application does not impose any restrictions on this.

[0405] S3. When the signature data is successfully verified, if the second summary data identical to the first summary data of the data unit being verified is found from the multiple second summary data of the authentication data, it is determined whether the second summary data identical to the first summary data of the data unit being verified is identical to the second summary data identical to the first summary data of the data unit that has been verified.

[0406] For example, the verification process of the signature data in S3 may refer to the description of the verification process of the signature data in S603 above, which will not be repeated here.

[0407] For example, when the signature data is successfully verified, the second digest data identical to the first digest data of the data unit being verified can be searched from the multiple second digest data of the authentication data. If the second digest data identical to the first digest data of the data unit being verified is found from the multiple second digest data of the authentication data, it is then determined whether the second digest data identical to the first digest data of the data unit being verified is identical to the second digest data identical to the first digest data of the data unit already verified.

[0408] Exemplarily, the verified data unit may refer to all verified data units (which may also be referred to as successfully authenticated data units); the verified data unit may be one or more.

[0409] S4. If the second summary data identical to the first summary data of the data unit being verified is not found from the multiple second summary data of the authentication data, or the second summary data identical to the first summary data of the data unit being verified is identical to the second summary data identical to the first summary data of the data unit that has been verified, it is determined that the authentication of the data unit being verified has failed.

[0410] S5. If the second digest data identical to the first digest data of the data unit being verified is different from the second digest data identical to the first digest data of the already verified data unit, it is determined that the authentication of the data unit being verified is successful.

[0411] For example, the authentication data is {digest data 21, digest data 22, ..., digest data 2n, signature}.

[0412] Assume that four data units have been verified: data unit 1, data unit 2, data unit 3, and data unit 4; the second digest data identical to the first digest data of these four verified data units are digest data 21, digest data 22, digest data 23, and digest data 24, respectively. If the second digest data identical to the first digest data of data unit 5 is digest data 21, then authentication of data unit 5 is determined to have failed. In other words, data unit 5 and data unit 1 are duplicates. If the second digest data identical to the first digest data of data unit 5 is digest data 25, then authentication of data unit 5 is determined to have succeeded.

[0413] Exemplarily, a corresponding preset identifier can be set for each second digest data in the authentication data, and the initial value of the preset identifier corresponding to each second digest data is a second preset value (the second preset value is 0 for illustration). When second digest data identical to the first digest data of the data unit being verified is found in the authentication data, it can be determined whether the value of the preset identifier corresponding to the second digest data is 0. If the value of the preset identifier corresponding to the second digest data is 0, it is determined that the second digest data identical to the first digest data of the data unit being verified is different from the second digest data identical to the first digest data of the data unit that has already been verified; at this point, it can be determined that the authentication of the data unit being verified is successful; and the value of the preset identifier corresponding to the second digest data can be set to a third preset value (the third preset value is different from the second preset value, and the third preset value is 1 for illustration). If the value of the preset identifier corresponding to the second digest data is 1, it is determined that the second digest data identical to the first digest data of the data unit being verified is identical to the second digest data identical to the first digest data of the data unit that has already been verified; at this point, it can be determined that the authentication of the data unit being verified has failed.

[0414] For example, the authentication data is {digest data 21, digest data 22, ..., digest data 2n, signature}; preset identifiers are set for digest data 21, digest data 22, ..., digest data 2n respectively; the values ​​of the preset identifiers corresponding to digest data 21, digest data 22, ..., digest data 2n are: 0, 0, ..., 0 respectively.

[0415] When the second digest data identical to the first digest data of data unit 1 is found in the authentication data as digest data 21, since the value of the preset identifier corresponding to digest data 21 is 0, it can be determined that authentication of data unit 1 is successful. The value of the preset identifier of digest data 21 is then set to 1; at this point, the values ​​of the preset identifiers corresponding to digest data 21, digest data 22, ..., digest data 2n are 1, 0, ..., 0, respectively.

[0416] When the second digest data identical to the first digest data of data unit 2 is found in the authentication data as digest data 22, since the value of the preset identifier corresponding to digest data 22 is 0, it can be determined that authentication of data unit 2 is successful. The value of the preset identifier of digest data 22 is then set to 1; at this point, the values ​​of the preset identifiers of digest data 21, digest data 22, ..., digest data 2n are 1, 1, ..., 0, respectively.

[0417] When the second digest data found in the authentication data that is identical to the first digest data of data unit 3 is digest data 21, since the value of the preset identifier corresponding to digest data 21 is 1, it can be determined that authentication of data unit 3 has failed. At this point, the values ​​of the preset identifiers corresponding to digest data 21, digest data 22, ..., digest data 2n are 1, 1, ..., 0, respectively.

[0418] It should be understood that there are multiple ways to determine whether the second digest data identical to the first digest data of the data unit being verified is identical to the second digest data identical to the first digest data of the data unit that has been verified, and this application does not impose any limitation on this.

[0419] Figure 7 is a schematic diagram of an exemplary code stream signature device. This schematic diagram of the code stream signature device can be used to execute 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.

[0420] 7 , illustratively, a code stream signature device 700 includes:

[0421] A first authentication data acquisition module 701 is configured to acquire authentication data; the authentication data includes signature data and summary data of each data unit in a group of data units in a code stream, wherein the signature data is obtained by signing the summary data of each data unit in the group of data units, and the summary data of each data unit in the group of data units is arranged in a first preset order;

[0422] The adding module 702 is configured to add authentication data to the code stream.

[0423] Exemplarily, the code stream signature device 700 further includes:

[0424] 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.

[0425] Exemplarily, the code stream signature device 700 further includes:

[0426] The signature module is used to connect the summary data of each data unit in a group of data units to determine the summary data of the connected summary data; and is used to use a private key to sign the summary data of the connected summary data to obtain signature data.

[0427] Exemplarily, the code stream signature device 700 further includes:

[0428] The authentication data generation module is used to generate authentication data according to the signature data, the summary data of each data unit in a group of data units and the first preset order.

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

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

[0431] For example, the multiple NAL units of each data unit in a group of data units are associated with each other according to a specified rule, and the decoding order of the multiple NAL units of each data unit in a group of data units is continuous. That is, one data unit is an access unit.

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

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

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

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

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

[0437] Exemplarily, the authentication data further includes: a second identifier, where the second identifier is used to identify a data unit.

[0438] Exemplarily, the code stream further includes: a sixth identifier; the code stream signature device 700 further includes

[0439] a value determination module, configured to determine a value n according to the sixth identifier; wherein a group of data units includes n data units, and n is a positive integer;

[0440] The summary data calculation module is further used to calculate each data unit in the n data units according to the summary algorithm to obtain summary data of each data unit in the n data units.

[0441] Figure 8 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.

[0442] 8 , illustratively, a code stream authentication device 800 includes:

[0443] A summary data determination module 801 is configured to determine first summary data of each data unit in a group of data units of a code stream;

[0444] A second authentication data acquisition module 802 is configured to acquire authentication data from the code stream, the authentication data including signature data and second digest data of each data unit in a group of data units, the signature data being signed based on the second digest data of each data unit in the group of data units, the second digest data of each data unit in the group of data units being arranged in a first preset order;

[0445] The verification module 803 is configured to verify the plurality of first summary data of a group of data units according to the plurality of second summary data in the authentication data, the first preset sequence and the second preset sequence when the signature data is successfully verified.

[0446] Exemplarily, the summary data determining module 801 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.

[0447] Exemplarily, the code stream authentication device 800 further includes:

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

[0449] The verification module 803 is used to concatenate the second summary data of each data unit in a group of data units to determine the summary data of the concatenated second summary data; and is also used to verify the signature data based on the public key, the summary data of the concatenated second summary data and the signature algorithm.

[0450] Exemplarily, the code stream authentication device 800 further includes:

[0451] 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;

[0452] When the value of the first identifier is the first preset value, the summary data determination module 801 determines first summary data of each data unit in a group of data units in the code stream.

[0453] Exemplarily, the identifier acquisition module is further configured to acquire a seventh identifier from the bitstream and determine a value n according to the seventh identifier; wherein a group of data units includes n data units, and n is a positive integer;

[0454] The code stream authentication device 800 further includes:

[0455] 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.

[0456] Exemplarily, the identifier acquisition module is further configured to acquire a sixth identifier from the bitstream and determine a value n according to the sixth identifier; wherein a group of data units includes n data units, and n is a positive integer;

[0457] The summary data determination module 801 is specifically configured to calculate each of the n data units according to a summary algorithm to obtain summary data of each of the n data units.

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

[0459] Exemplarily, the verification module 803 is specifically configured to verify the first summary data of each data unit in a group of data units in sequence according to a second preset order; wherein, the verification process for the first summary data of the first data unit in a group of data units is as follows: obtaining a first position; wherein, the first position is determined based on the position of the second summary data identical to the first summary data of the data unit successfully authenticated in the previous time, in multiple second summary data of the authentication data; the position of the second summary data identical to the first summary data of the data unit successfully authenticated in the previous time, in multiple second summary data of the authentication data, is determined based on the first preset order; and the first summary data of the first data unit is verified based on the first position and the multiple second summary data in the authentication data.

[0460] Exemplarily, the verification module 803 is specifically configured to determine a second position according to a first preset order when there is second summary data identical to the first summary data of the first data unit among multiple second summary data of the authentication data, the second position referring to the position of the second summary data identical to the first summary data of the first data unit in the multiple second summary data of the authentication data; determine whether the second position is located after the first position; if the second position is located after the first position, determine that the authentication of the first data unit is successful; if the second summary data identical to the first summary data of the first data unit is not found in the multiple second summary data of the authentication data, or the second position is located before the first position, or the second position is the same as the first position, determine that the authentication of the first data unit has failed.

[0461] Exemplarily, the authentication data also includes multiple second identifiers, and the multiple second identifiers correspond one-to-one to the multiple second summary data. The identifier acquisition module is used to obtain the third identifier corresponding to each data unit in a group of data units from the code stream; the verification module 803 is specifically used to search for a second identifier that is identical to the third identifier of the first data unit from the multiple second identifiers included in the authentication data; if there is a second identifier that is identical to the third identifier of the first data unit, then compare the first summary data of the first data unit and the second summary data corresponding to the second identifier that is identical to the third identifier of the first data unit; if the two are the same, then determine that among the multiple second summary data of the authentication data, there is second summary data that is identical to the first summary data of the first data unit; otherwise, determine that among the multiple second summary data of the authentication data, there is no second summary data that is identical to the first summary data of the first data unit.

[0462] Exemplarily, the verification module 803 is specifically configured to search for second digest data that is identical to the first digest data of the first data unit from the multiple second digests included in the authentication data.

[0463] Exemplarily, the verification module 803 is specifically configured to search backward starting from the first position among multiple positions corresponding to multiple second summary data of the authentication data; if second summary data identical to the first summary data of the first data unit is found, 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.

[0464] For example, the multiple NAL units of each data unit in a group of data units are associated with each other according to a specified rule, and the decoding order of the multiple NAL units of each data unit in a group of data units is continuous. In other words, one data unit is one access unit.

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

[0466] In an example, FIG9 shows a schematic block diagram of a device 900 according to an embodiment of the present application. The device 900 may include: a processor 901 and a transceiver / transceiver pin 902 , and optionally, a memory 903 .

[0467] The various components of the device 900 are coupled together via a bus 904, wherein the bus 904 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 904 in the figure.

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

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

[0470] 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.

[0471] 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. When the one or more processors execute computer instructions, the steps of the above-mentioned related methods are implemented. The interface circuit is a transceiver / transceiver pin 902.

[0472] 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.

[0473] 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.

[0474] 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.

[0475] 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.

[0476] 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.

[0477] 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.

[0478] 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.

[0479] 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.

[0480] 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.

[0481] 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.

[0482] 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.

[0483] 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.

[0484] 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 method comprises: Acquire authentication data; wherein the authentication data includes: signature data and summary data of each data unit in a group of data units of the bit stream, the signature data is obtained by signing according to the summary data of each data unit in the group of data units, and the summary data of each data unit in the group of data units is arranged in a first preset order; The authentication data is added to the bit stream.

2. The method according to claim 1, characterized in that The first preset order is the arrangement order of each data unit in the group of data units in the bit stream.

3. The method according to claim 1 or 2, 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.

4. The method according to claim 3, 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.

5. The method according to any one of claims 1 to 4, 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.

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

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

8. The method according to any one of claims 1 to 7, 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.

9. The method according to claim 8, characterized in that The summary data of each data unit in the group of data units in the summary data list is arranged according to the first preset order.

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

11. The method according to claim 10, 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.

12. The method according to any one of claims 1 to 11, characterized in that: The bit stream further includes a first identifier, which indicates an authentication mode adopted by the group of data units.

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

14. A bit stream, characterized in that The bit stream comprises: A set of data units and authentication data; Wherein, the authentication data includes: signature data and summary data of each data unit in the group of data units, the signature data is obtained by signing based on the summary data of each data unit in the group of data units, and the summary data of each data unit in the group of data units is arranged according to a first preset order.

15. The bit stream according to claim 14, 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.

16. The bit stream according to claim 15, characterized in that The summary data of each data unit in the group of data units in the summary data list is arranged according to the first preset order.

17. The bit stream according to any one of claims 14 to 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 any one of claims 14 to 18, characterized in that The bit stream further includes a first identifier, which indicates an authentication mode adopted by the group of data units.

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

21. A method for authenticating a bit stream, characterized in that: The method comprises: determining first summary data for each data unit in a set of data units of the bitstream; Acquire authentication data from the bit stream, the authentication data comprising: signature data 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, the second summary data of each data unit in the set of data units being arranged in a first preset order; When the signature data is successfully verified, 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, the first preset sequence and the second preset sequence.

22. The method according to claim 21, characterized in that The first preset order and the second preset order are both the arrangement order of each data unit in the group of data units in the bit stream.

23. The method according to claim 21 or 22, 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.

24. The method according to any one of claims 21 to 23, 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.

25. The method according to claim 24, characterized in that The method further comprises: The signature data is verified according to the summary data of the connected second summary data and the signature algorithm.

26. The method according to any one of claims 21 to 25, 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 first summary data of each data unit in a group of data units of the bit stream is performed.

27. The method according to any one of claims 21 to 26, 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, the first preset order, and the second preset order comprises: According to the second preset order, the first summary data of each data unit in the group of data units is verified in turn; wherein the verification process for the first summary data of the first data unit in the group of data units is as follows: Obtaining a first position; wherein the first position is determined according to the position of the second summary data identical to the first summary data of the data unit successfully authenticated last time in the plurality of second summary data of the authentication data; the position of the second summary data identical to the first summary data of the data unit successfully authenticated last time in the plurality of second summary data of the authentication data is determined according to the first preset order; The first digest data of the first data unit is verified according to the first position and a plurality of second digest data in the authentication data.

28. The method according to claim 27, characterized in that The method further comprises: From the plurality of second digest data included in the authentication data, second digest data identical to the first digest data of the first data unit is searched.

29. The method according to claim 27 or 28, characterized in that The verifying the first summary data of the first data unit according to the first position and the plurality of second summary data in the authentication data comprises: Search backward from the first position among the plurality of positions corresponding to the plurality of second summary data of the authentication data; If the second summary data that is the same as the first summary data of the first data unit is found, it is determined that the authentication of the first data unit is successful; Otherwise, it is determined that the authentication of the first data unit fails.

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

31. 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 bitstream signing method as described in any one of claims 1 to 13, or to execute a bitstream authentication method as described in any one of claims 21 to 30.

32. 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 13, or executes the method according to any one of claims 21 to 30.

33. 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 13 are executed, or the steps of the method according to any one of claims 21 to 30 are executed.

34. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a bit stream according to any one of claims 14 to 20.

Images