Transcodable signed video data

Abstract

Transcodable signed video data is disclosed. In particular, the disclosure provides a method of a signed video bitstream adapted for transcoding from a first video format into a second video format, the method comprising: obtaining first video data of the first video format with loss; reconstructing a video sequence from the first video data; encoding the reconstructed video sequence into second video data of the second video format; computing a first fingerprint of the first video data and a second fingerprint of the second video data; deriving a first bit string from the first fingerprint and a second bit string from the second fingerprint; and providing a signed video bitstream comprising the first video data and signed units, each signed unit comprising a first digital signature of the derived first bit string and a second digital signature of the derived second bit string.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to the field of secure deployment for protecting video data from unauthorized activities, especially with respect to activities on storage and transmission of data. It proposes methods and apparatus for providing a signed video bitstream adapted for transcoding from a first video format into a second video format. It further proposes methods and apparatus for transcoding and verifying a signed video bitstream. BACKGROUND

[0002] Digital signatures provide a layer of authentication and security for digital messages transmitted over non-secure channels. With digital signatures, the authenticity or integrity of a message can be verified, and non-repudiation can be ensured. Especially with respect to video coding, there are secure and efficient methods for digitally signing a predictively coded video sequence, which have been described in the prior art. See, for example, the present inventor’s earlier patent applications EP21201360.1 and EP21201362.7. The usual practice is to provide a signature not on the original video sequence, but on the video data representing it in encoded form (or possibly on data derived from the video data by some pre-agreed rules), and to add the signature to the video bitstream. The video bitstream after the signature can thus consist of the video data, the signature, and any metadata. The video bitstream is verified by performing a pre-agreed operation on the video data to confirm that it matches the signature.

[0003] Due to the significant diversity among playback devices on the market, especially in today's video streaming applications, it happens quite frequently that an end user finds himself unable to play a received video bitstream because of the lack of a decoder supporting the format of the video file. Requiring all playback devices to support all video formats would solve the compatibility problem, but this is not an economically viable solution considering the quite high cost pressure on consumer electronics. Alternatively, compatibility can be restored by transcoding the video bitstream from its original format to a video format suitable for the playback device of the end user. Transcoding can be performed by the playback device itself, or by a different device such as a host computer serving a group of end users. In one example, a video bitstream can be transcoded from ITU-T H.265 format to ITU-T H.264 format. In another example, a video bitstream can be transcoded from ITU-T H.265 format configured with a first set of parameters to ITU-T H.265 format configured with a different second set of parameters. In general, transcoding can include the use of a new encoder in which one or more building blocks constituting a video encoding format have been replaced, for example the frequency domain transform or encoding method to be applied to the pixel data is selected. Moreover, transcoding can include the use of a new encoder in which a parameter value defined as variable in a given video encoding format has been modified, for example the target bit rate, the quantization step, the scaling factor, the group of pictures (GOP) structure, the number of reference frames or the search range for motion estimation.

[0004] From transcoded video data, the video sequence can be reconstructed without many visible defects, that is to say that the end user will hardly notice that the played video sequence is reconstructed from the received video bitstream or from the transcoded version. However, if the video bitstream contains a signature that has been provided based on the video data, it is clear that the transcoding operation will thoroughly change the underlying video data so that it no longer matches the signature. In fact, a user-initiated legitimate transcoding operation can lead to a verification that is invalid in a way that cannot be distinguished from an unauthorized tampering. Then, the user can have to accept the use of the transcoded video bitstream without certainty of its authenticity.

[0005] It is noted that the Applicant's earlier application EP3968636A1 discloses a way of signing a video bitstream designed to be trimmable, i.e. a video bitstream that allows the removal of one or more video frames. Here, because a structured hierarchical encoding method is followed, the effect of the trimming action will be fully predictable. Therefore, the video can be signed without additional effort so that the user is able to verify the authenticity of each permutation of the video data remaining after trimming. As used in the present disclosure, the term transcoding does not extend to pure trimming.

[0006] Similarly, US patent 7581094B1 discloses a method for ensuring the integrity of secure, scalable, and streamable media data. According to this method, a quantity of media data is divided into segments comprising multiple truncation units, and an encrypted checksum is calculated for each segment. Here, a truncation unit is a portion of the packet payload that can be truncated from the packet payload without adversely affecting the remainder of the packet. The segmented media data is claimed to be suitable for reducing bandwidth through “transcoding” as stated herein. In the terminology of US 7581094B1, “transcoding” can refer to the truncation of a portion of the packet payload, or it can refer to the deletion of an entire packet. Again, note that in the context of this disclosure, the term transcoding does not cover such truncation and packet deletion.

[0007] In the existing technology, the problem of providing a signed video bitstream suitable for transcoding between two video formats has not been satisfactorily solved. Summary of the Invention

[0008] One object of this disclosure is to provide a method suitable for transcoding a signed video bitstream from a first video format to a second video format. A specific object is to retain the receiver's ability to verify the video bitstream even after the receiver has transcoded the video bitstream into a different video format. To keep the total bitrate within limits, a further object is to provide a method to support lossy video formats, for which reconstruction may be imperfect. Similarly, transcoding capabilities should be achieved at the cost of no more than a modest increase in the total bitrate and / or without introducing significant new procedures on the receiver's side. Another object is to provide a method for verifying a signed video bitstream that has undergone transcoding, particularly when transcoding is performed by a transcoding entity that is not fully trusted. Yet another object is to provide apparatus and computer programs for these purposes.

[0009] At least some of these objectives are achieved by the invention as defined in the independent claim. The dependent claims relate to advantageous embodiments.

[0010] In a first aspect of this disclosure, a method is proposed for providing a signed video bitstream suitable for transcoding from a first video format to a second video format. The method includes: acquiring first video data in a lossy first video format; reconstructing a video sequence from the first video data; encoding the reconstructed video sequence into second video data in a second video format; calculating one or more first fingerprints of the first video data and one or more second fingerprints of the second video data; deriving at least one first bit string from the first fingerprint and at least one second bit string from the second fingerprint; and providing a signed video bitstream comprising the first video data and one or more signature units, each signature unit comprising a first digital signature of the derived first bit string and a second digital signature of the derived second bit string. The signature unit may optionally include the derived first bit string and the second bit string (“Document Method”).

[0011] According to the foregoing portion of the invention, it should be understood that the term "transcoding" is used in the sense of excluding bandwidth reduction or bitrate reduction operations, for which the video bitstream has been pre-prepared, whether by truncating truncation units, discarding unimportant data packets, trimming dedicated video frames, or any similar techniques. Therefore, the method of the first aspect neither presupposes that the second video data is a subset of the first video data, nor presupposes that the first and second video data have substantial overlap. In the context of the method of the first aspect, the first and second video data, both relating to the same video sequence, preferably have substantially zero overlap.

[0012] In the context of this disclosure, the first "video format" and the second "video format" can be different video coding formats such as ITU-T H.264, ITU-T H.265, or AV1. The two video coding formats can differ, for example, through different choices of frequency domain transforms (e.g., DCT, DST, DFT, wavelet transform) or coding methods (e.g., entropy, Huffman, Lenper-Ziff, run-length, binary or non-binary arithmetic coding, such as context-adaptive variable-length coding, CAVLC, context-adaptive binary arithmetic coding, CABAC) with respect to one or more of their building blocks. Alternatively, the first video format and the second video format can be different instances of the same video coding format, wherein different parameter assignments have been used for the two instances. For example, the instances can differ with respect to the values ​​of parameters defined as variable in the same video coding format (e.g., target bitrate, quantization step size, scaling factor, group of pictures (GOP) structure, number of reference frames, or search range for motion estimation).

[0013] The inventors have devised a method according to the first aspect, such that the reconstruction of the video sequence and the encoding of its second video format are equivalent to the operations that occur when the receiver of the video bitstream transcodes it into the second video format. Therefore, the receiver will be able to use the second digital signature in the signature unit to verify the video data in the second format resulting from the transcoding. This capability is ensured only by extending the signature unit with the second digital signature (and optionally a second bit string), which in practice represents a very limited increase in bit rate.

[0014] In some embodiments, the first digital signature is independent of the second digital signature. This allows the receiver to verify the second video data without accessing the second bit string from the sender, i.e., by deriving the second bit string based on the transcoded video data and verifying the derived bit string using the second digital signature. In other embodiments (“Document Method”), the signing unit comprises the first bit string and the second bit string, as well as a digital signature common to both; in other words, “first digital signature” and “second digital signature” refer to the same digital signature. (It should be understood that each bit string in the bit string is a combination of individual fingerprints or a fingerprint of said combination of individual fingerprints). Using a single digital signature limits the number of calls to the (external) cryptographic entity that provides the digital signature. In yet another embodiment, the signing unit comprises the first bit string and the second bit string, as well as a digital signature for each bit string. If the signing unit comprises two digital signatures, processing of one of these may become redundant in some cases (e.g., if the receiver intends to use the signed video bit stream without transcoding). In fact, the possible combinations of digital fingerprints of the first and second video data that form a public fingerprint can make the verification process more complicated for the recipient in some implementations, even if the video sequence is to be consumed in the first video format, the signed video bitstream still needs to be transcoded into the second video format.

[0015] In some embodiments, the first bit string is linked to the second bit string, or the second bit string is linked to the first bit string. In other words, the first bit string will depend on the second bit string, and vice versa. It should be understood that the first (second) bit string is derived from one or more first fingerprints of the first (second) video data. Here, the fingerprint can be a hash (or salted hash) of a video frame or a macroblock in a video frame. In embodiments where the first and second bit strings are linked, the receiver will be able to detect whether the video bitstream has undergone unauthorized editing and / or whether one of the bit strings has been replaced. In specific cases where the signature unit includes the first bit string, the second bit string, a first digital signature of the first bit string, and a second digital signature of the second bit string, the linking can allow the receiver to discover attacks in which an unauthorized third party has simultaneously replaced both the first video data and the first bit string.

[0016] In some embodiments, the first video data comprises a sequence of video data units, and a first fingerprint is calculated for each video data unit and sequentially linked. It should be understood that the video data units may be sequential in time or space. Video data units may be, for example, macroblocks or video frames. In these embodiments, alternatively or additionally, the second video data comprises a sequence of video data units, and a second fingerprint is calculated for each video data unit and sequentially linked. Optionally, both the first and second fingerprints are linked in this way.

[0017] In some embodiments, the first video data is necessary for reconstructing the video sequence from the signed video bitstream. For example, the signed video bitstream may not contain any data other than the first video data that would allow for a complete reconstruction of the video sequence. In particular, the second video data may not be present in the signed video bitstream; the second video data is used to calculate the second fingerprint when the method of the first aspect is performed, and can then be discarded. In another example, the signed video bitstream consists of the first video data, one or more signature units, and optional metadata.

[0018] In some embodiments, the signed video bitstream further includes metadata identifying a second video format. The second video format can be identified according to the video encoding format (e.g., a standardized format such as ITU-T H.264) and / or according to the assignment of one or more configurable parameters of the video encoding format. Although a generic decoder can sometimes be used for some video encoding formats, knowledge of these parameter values ​​may be necessary for correct encoding. The advantage of including metadata identifying the second video format (and any other supported video formats) is that the receiver knows the scope of transcoding; that is, the receiver is informed that the signed video bitstream can be transcoded into video formats while still allowing verification of its authenticity. It should be understood that the first video format is known to the receiver or can be identified based on the first video data itself, for example, by examining the file identifier, header structure, or other features already incorporated into the video data through embedding or encapsulation. Thus, a (unique) standards-compliant decoder can be used to reconstruct the video sequence so that the second video data generated in the next step will be consistent with the signing unit. In embodiments where the signed video bitstream lacks information identifying the second video format, the identity of the second video format may be known to the receiver.

[0019] In some embodiments, each signature unit is associated with a segment of a video bitstream that includes at least one group of pictures (GOP) for signing. Preferably, the segment corresponds to one or more complete GOPs. In the context of predictive video coding, and as used in this disclosure, a GOP is a subsequence of video frames that does not involve any video frames outside of that subsequence; it can be decoded without reference to any other video frames. These embodiments tend to reduce the number of digital signatures to be processed at the receiving end, and thus reduce the number of calls to cryptographic entities with this capability. Alternatively, if a GOP is allowed to be split between two signature units (i.e., associated with both signature units), the decoding of a particular video frame may in some cases also require processing a second signature unit in order to decode such other video frames that are directly or indirectly involved with that particular video frame. Furthermore, these embodiments can contribute to a smaller-granularity verification process in the sense that the impact of including invalid verification in a limited number of video frames. In certain embodiments of these embodiments, the interval between two consecutive signature units can be at least 1 minute of playback time, preferably at least 5 minutes of playback time, and more preferably at least 10 minutes of playback time.

[0020] In some embodiments, the signed video bitstream can be transcoded not only into a second video format, but also into a third video format, a fourth video format, etc. This is achieved by encoding the video sequence reconstructed from the first video data in a third video format, calculating a third fingerprint from the third video data, deriving a third bit string H3 from the third fingerprint, and providing its third digital signature. The third digital signature is included in the signature unit to ensure that the third bit string H3, optionally together with the third bit string H3 itself, is included. As described above, the digital signature of the third bit string H3 can be common to multiple bit strings (e.g., s([H1,H2,H3])), or it can be a separate digital signature s(H3). The recipient of the video bitstream possessing the signature is free to perform transcoding from the first video format to the third video format. Alternatively, as described, the method includes encoding the video sequence reconstructed from the second video data in a third video format, calculating an alternative fingerprint from the third video data, deriving an alternative third bit string H3′ from the third fingerprint, and including the digital signature of the alternative third bit string H3′ in the signature unit. Optionally, an alternative third bit string H3′ may also be included. A receiver of the video bitstream possessing this alternative signature is free to perform transcoding from the second video format to the third video format (which may actually require pre-transcoding the first video data to the second video format). Further alternatively, with very little additional overhead, the signed video bitstream may include a digital signature of the third bit string H3 and an alternative third bit string H3′ (and optionally, these bit strings as well), allowing the receiver free to choose either transcoding path leading to the third video format (1→3 or 1→2→3).

[0021] In a second aspect of this disclosure, a method for transcoding and verifying a signed video bitstream is provided, wherein the signed bitstream comprises first video data in a lossy first video format and one or more signature units, each signature unit comprising a first digital signature associated with the video data in the first video format and a second digital signature associated with video data obtainable by transcoding to a second video format, and optionally, a first bit string and a second bit string. The method includes: reconstructing a video sequence from the first video data; encoding the reconstructed video sequence into second video data in a second video format; calculating one or more fingerprints of the second video data; deriving a bit string from the calculated fingerprints; and verifying the second video data using the second digital signature. A final verification step may also include verifying the derived bit string using the second digital signature. Alternatively (“Document Method”), the verification step includes verifying the second bit string in the one or more signature units using the digital signature and comparing the derived bit string with the verified second bit string.

[0022] The receiver of the signed video bitstream has the option to consume first video data in a first video format (e.g., to replay a video sequence using a decoder for the first video format). The receiver also has the option to perform the method according to the second aspect, which would enable the receiver to consume second video data in a second video format, for example, for replay using a decoder suitable for the second video format. Regardless of which option the receiver chooses, he or she can verify the video bitstream using the content of the signing unit (i.e., verify the authenticity of the video bitstream). This flexibility is achieved at the cost of only minimal additional overhead, which negligibly increases the total bitrate of the signed video bitstream in most use cases. This flexibility also eliminates the need for any specialized or non-standard operations at the receiver end, which would otherwise hinder or slow the adoption of the proposed method in consumer devices. In summary, the method according to the second aspect shares many of the advantages associated with the first aspect, and it can be implemented with an equivalent degree of technical variation.

[0023] The method for transcoding and verifying the signature of a video bitstream can be performed jointly or collaboratively (i.e., by work distribution between different entities or by a single entity, albeit at different times). In this sense, the method can be considered as two sub-methods. The first sub-method, primarily representing the transcoding aspect, includes: reconstructing a video sequence from first video data; and encoding the reconstructed video sequence into second video data in a second video format. The second sub-method, primarily involving verifying the transcoded video data and optionally consuming (e.g., playing it) it upon a positive verification result, includes: calculating one or more fingerprints of the second video data; deriving a bit string from the calculated fingerprints; and verifying the second video data using a second digital signature (e.g., utilizing the second digital signature to perform operations to determine whether the derived bit string is authentic). Optionally, the first sub-method includes forming a new signed bitstream from the original bitstream, comprising the second video data and one or more signature units but excluding the first video data. This new signed bitstream is the input to the second sub-method.

[0024] In a third aspect of this disclosure, a signed video bitstream is provided, comprising: first video data in a lossy first video format and one or more signature units. Each signature unit includes at least a first digital signature and a second digital signature. The first digital signature is a signature of at least a first bit string derived from a first fingerprint calculated from the first video data, and the second digital signature is a signature of at least a second bit string derived from a second fingerprint calculated from second video data obtained by reconstructing a video sequence from the first video data encoded in a second video format. The signature unit may optionally include the first bit string and the second bit string. The signed video bitstream may be stored or distributed on a data carrier. As used herein, "data carrier" can be a temporary data carrier such as modulated electromagnetic waves or light waves, or a non-temporary data carrier. Non-temporary data carriers include volatile and non-volatile memories, such as permanent and non-permanent storage media of magnetic, optical, or solid-state types. Still within the scope of "data carrier," such memory can be fixedly mounted or portable.

[0025] The video bitstream signed according to the third aspect is particularly suited to the intended technical use by the receiver, namely, for direct consumption in a first video format or transcoding to a second video format, with the ability to verify its authenticity each time. Generally, the signed video bitstream shares many of the advantages associated with the first and second aspects of this disclosure, and it can be implemented with an equivalent degree of technical variation.

[0026] In a fourth aspect of this disclosure, an apparatus is provided that includes processing circuitry arranged to perform the methods of the first or second aspect.

[0027] The apparatus according to the fourth aspect shares many advantages associated with the first and second aspects of this disclosure, and it can be implemented with an equivalent degree of technical variation.

[0028] This disclosure further relates to a computer program containing instructions for causing a computer (or, in particular, the aforementioned apparatus) to perform the methods described above. In the sense already defined, a computer program can be stored or distributed on a data carrier.

[0029] Generally, unless expressly defined herein, all terms used in the claims should be interpreted according to their ordinary meaning in the art. Unless otherwise expressly stated, all references to “a / an / the element, device, component, means, step, etc.” should be openly interpreted as referring to at least one instance of that element, device, component, means, step, etc. Unless expressly stated otherwise, the steps of any method disclosed herein need not be performed in the order described. Attached Figure Description

[0030] Aspects and embodiments will now be described by way of example with reference to the accompanying drawings, in which:

[0031] Figure 1A The illustration illustrates the provision of a signed video stream that allows transcoding from at least a first video format to a second video format according to embodiments herein (“Documentary Method”);

[0032] Figure 1B Described Figure 1A An alternative to the previous method, in which the signature unit has different content;

[0033] Figure 2 This is a flowchart of a method for providing a signed video bitstream suitable for transcoding from a first video format to a second video format, according to embodiments herein;

[0034] Figure 3 This is a flowchart of a method for transcoding a signed video bitstream from a first video format to a second video format and verifying it according to embodiments herein;

[0035] Figure 4A The illustration shows the transcoding of a signed video stream from a first video format to a second format according to embodiments herein, and the operation for verifying the video data provided by the transcoding (“Document Method”).

[0036] Figure 4B Description in Figure 4A An alternative to the method seen in the example, in which the signature unit has different content;

[0037] Figure 5 Showing what is suitable for execution Figure 2 and Figure 3 The apparatus of the method illustrated in the figure; and

[0038] Figure 6 Multiple such devices are shown connected via a local area network (LAN), a wide area network (WAN), or both. Detailed Implementation

[0039] In the following description, aspects of this disclosure will be described more fully with reference to the accompanying drawings, on which specific embodiments of the invention are illustrated. However, these aspects may be embodied in many different forms and should not be construed as limiting; rather, these embodiments are provided by way of example so that this disclosure will be thorough and complete, and will fully convey the scope of all aspects of the invention to those skilled in the art. Throughout the specification, the same reference numerals refer to the same elements.

[0040] Technical framework

[0041] In the terminology of this disclosure, a “video bitstream” includes any substantially linear data structure that can resemble a sequence of bit values. A video bitstream can be stored or transmitted on a data carrier; see the example above. A video bitstream represents a sequence of video frames that can be understood as being played sequentially at nominal time intervals. Each video frame can be divided into macroblocks, such as transform blocks or prediction blocks, or blocks serving both purposes. The use of “frame” and “macroblock” in this document is intended to be consistent with the H.26x video coding standard or similar specifications.

[0042] Figure 1A A portion of a video bitstream 100 is depicted, comprising a first data unit 110 of a first video format and a signature of a signature unit 130 associated with the first data unit 110. The video bitstream 100 represents an original video sequence (not shown) comprising five consecutive video frames. Video frames have been encoded into first data units 110 using predictive or non-predictive coding. Predictive coding can be performed about the entire frame or about a macroblock location (e.g., about top left, top right, bottom left, bottom right if a 2×2 macroblock partition is used). As shown, a one-to-one correspondence may exist between the first data units 110 and video frames. Alternatively, each video frame is encoded as M ≥ 1 first data units 110, where M can be fixed or variable on the video frame. Further alternatively, each of the first data units 110 represents N ≥ 1 video frames, where N can be fixed or variable. In yet another variation, each data unit 110 may be allowed to represent any number of frames in the original video sequence, and each video frame may be encoded by any number of data units 110. For the purposes of this disclosure, data units (including Figure 1A The first data unit 110 and the second data unit 120 shown in the diagram can have any suitable format and structure. No assumptions are made except that the data units can be separated (or extracted) from the video bitstream, to allow, for example, that the data units can be processed without any need to decode that data unit or any surrounding data units. The first data unit 110 can conform to proprietary or standardized video coding formats such as ITU-T H.264, H.265, or AV1.

[0043] In addition to Figure 1A In addition to the first data unit 110 and associated signature unit 130 shown at the top, the signed video bitstream 100 may include other types of units. For example, without departing from the scope of this disclosure, the bitstream 100 may include dedicated metadata units. The signature unit 130 may be separable from the signed video bitstream 100 in the same or similar manner as the first data unit 110. Each of the signature units 130 can be associated with a plurality of first data units 110.Figure 1A It should be understood that a first data unit 110 between two consecutive signature units 130 is associated with a subsequent signature unit 130. This rule for associating the first data unit 110 and the signature unit 130 is not a necessary feature of the invention, and other rules are possible without departing from the scope of this disclosure. For example, a signature unit 130 may be associated with a set of first data units 110 corresponding to a group of pictures (GOP) (e.g., the GOP immediately preceding the signature unit 130). In ITU-T H.264 and H.265 formats, the signature unit 130 may be included in the video bitstream 100 as a Supplemental Enhancement Information (SEI) message. In the AV1 standard, the signature may be included in the Metadata Open Bitstream Unit (OBU).

[0044] Each of the signature units 130 includes a fingerprint h from those first data units 110 associated with the signature unit 130. 11 ,h 12 ,h 13 The digital signature s(H1) of the first bit string H1 derived from it. Optionally, signature unit 130 also includes the first bit string H1. According to the embodiment described below, signature unit 130 may further include a fingerprint h from an associated second data unit 120 representing the same original video sequence, although in a second video format. 21 ,h 22 ,h 23 The digital signatures s(H2) of the second bit string H2 derived from H2 are also possible. Similarly, the signature unit 130 may optionally include the second bit string H2. When the signature unit 130 includes multiple bit strings, the signature unit 130 may have a single digital signature for all of these bit strings (e.g., a concatenation of these bit strings), multiple digital signatures for each individual bit string, or multiple digital signatures for each subgroup of bit strings.

[0045] fingerprint h 11 ,h 12 ,h 13The hash, ..., can be a hash or a salted hash of the first data unit 110. The fingerprint and the first data unit 110 can have a one-to-one or one-to-many relationship. The hash can be generated by a hash function (or one-way function) h, which provides a cryptographic function deemed to have a sufficient level of security given the sensitivity of the video data to be signed and / or the value that would be at risk if the video data were manipulated by an unauthorized party. Three examples are SHA-256, SHA3-512, and RSA-1024. The hash function should be predefined (e.g., it should be reproducible) so that the fingerprint can be regenerated when the recipient wants to verify it. A salted hash can be a hash of a combination of a data unit (or a portion of a data unit) and a cryptographic salt; the presence of the salt prevents an unauthorized party with access to multiple hashes from guessing which hash function is being used. Potentially useful cryptographic salts include the value of an internal counter, a random number, and the time and place of the signature.

[0046] fingerprint h 11 h 12 The fingerprint is calculated directly from the first data unit 110, for example, from the transform coefficients or other video data therein. The fingerprint can be calculated from the entire data unit or from a subset of data units extracted according to pre-agreed rules. The fingerprint can be written as h. 11 =h(X) 110.1 )or or Among them, X 110.1 The data comes from the first data unit 110, and σ is the cryptographic salt. In the third option, the hash function h is parametrically dependent on the second parameter to which the salt σ has been assigned. In this disclosure, the square bracket symbol [·] refers to a general data combination operation that may include linear (juxtaposed) or various interleaved arrangements of data. Combination operations may further include arithmetic operations on the data, such as bitwise OR, XOR, multiplication, division, or modulo operations. Alternatively, the fingerprint is calculated from the reconstructed macroblock or frame obtained by decoding data unit 110: h 11 =h(Y 110.1 )or or Among them, Y 110.1 σ represents the first reconstructed pixel value or other plaintext data from the first data unit 110, and σ is the cryptographic salt.

[0047] Optionally, to detect unauthorized removal or insertion of data units, fingerprints can be sequentially chained together. That is, each fingerprint depends on the next or previous fingerprint; for example, the input to the hash includes the hash of the next or previous fingerprint. Chaining can be implemented, for example, as follows: h 11 =h ( X110.1 ), h 12 =h([h 11 X 110.2 ]), h 13 =h([h 12 X 110.3 ]) etc., among which, X 110.2 X 110.3 This represents the second and third data from the first data unit 110. Another way to link fingerprints is: h 11 =h(X) 110.1 ), etc.

[0048] The bit string H1 in signature unit 130 can be the fingerprint h of the associated first data unit 110. 11 h 12 h 13 ,...combination:

[0049] H1 = [h 11 h 12 h 13 ,...],

[0050] Alternatively, it could be the fingerprint of the combination of the fingerprints associated with the first data unit 110:

[0051] H1=h([h 11 h 12 h 13 ,...]).

[0052] In the second option, the fingerprint h used to generate the associated first data unit 110 can be used. 11 h 12 h 13 The hash function used to generate the bit string H1 is the same as that used for the hash function; alternatively, two different hash functions can be used. As the square brackets suggest, the combination of fingerprints (or "documents") can be a list of string representations of fingerprints or other concatenations.

[0053] Referring again to signature unit 130, a cryptographic element with a pre-stored private key can be used to generate a digital signature s(H1) of the bit string H1 therein. The recipient of the signed video bitstream may be assumed to hold the public key belonging to the same key pair; see [link to relevant documentation]. Figure 4A and 4BElement 401 in the code. The public key enables the receiver to verify the authenticity of the data associated with the digital signature s(H1) generated by the sender's cryptographic elements, but cannot generate new signatures. The public key can also be included as metadata in the signed video bitstream; in this case, there is no urgent need to store the public key on the receiver's side.

[0054] Methods for providing signed video sequences

[0055] refer to Figure 2 A method 200 for providing a signed video bitstream 100 suitable for transcoding from a first video format to a second video format will now be described. If the original video sequence was acquired using a recording device, method 200 can be performed in the recording device or in a different device associated with or connected to the recording device via a secure communication channel. Signatures become particularly relevant when the video bitstream is to be transmitted over an unreliable communication channel or stored in an unreliable external memory.

[0056] The apparatus for performing method 200 may be an application or system dedicated to a specific purpose, or it may be a device with Figure 5 The figure shows a general-purpose data processing device with a basic functional structure. As shown, the device 500 includes a processing circuit 510, a memory 520, and an external interface 530. The memory 520 may be adapted to store a computer program 521 having instructions for implementing method 200. The external interface 530 may be a communication interface that allows the device 500 to communicate with a compatible device (not shown) held by a receiver and / or video content author (e.g., a recording device), or it may allow read and write operations in an external memory 590 adapted to store video bitstreams.

[0057] Figure 6 The illustration shows the transmission of video bitstreams between multiple devices. It should be noted that the device 500 performing editing method 200 can do so via a local area network (LAN). Figure 6 The lower half of the connection cable) or WAN 690 is connected to the receiving device 500. The fact that an attack on the video bitstream 100 can occur on any type of network proves the validity of the signature.

[0058] return Figure 2 One embodiment of method 200 is to acquire first video data therein. First step 210 Begin. First video data (e.g., in...) Figure 1A The first data unit 110 seen in the image is preferably a lossy first video format. The first video data can be obtained by encoding the original video sequence in the first video format using encoder software or encoder hardware provided for this purpose. Alternatively, the first video data is input data to the apparatus or process performing method 200.

[0059] exist Second step 212 In this process, video sequence 140 is reconstructed from the first video data. This can be used in... Figure 1A and Figure 1B The reconstruction is performed by decoder software or hardware, denoted as Dec1, suitable for the first video format, and the output is pixel values ​​or other plaintext data. It should be noted that because the prediction reference should be the reconstructed video frame or macroblock (i.e., obtained by encoding and then decoding), rather than the original video frame or macroblock, the prediction encoder product inherently includes a decoder portion. Since the first video format is preferably a lossy video format, the reconstructed video sequence 140 may differ slightly from the original video sequence. Several lossy video formats that achieve significant data compression at the expense of only limited visual degradation have been described in the prior art. In addition to the visual aspects, if the transcoded video data is to remain verifiable at the receiver, the second step 212 preferably uses a decoder Dec1 conforming to a standard or equivalent pre-agreed specification. For example, if a proprietary decoder product further includes a post-processing step (e.g., post-filtering) in addition to the specified operation, this post-processing step is preferably disabled so that the reconstructed video sequence 140 is suitable as input to the next step 214; or, the reconstructed video sequence 140 can be extracted as an intermediate variable from a non-standard decoding process.

[0060] exist Third step 214 In this process, video sequence 140, reconstructed using a second video format, is used to obtain second video data. The second video format can also be a lossy video format. Figure 1A This is illustrated in the diagram by applying encoder software or encoder hardware suitable for a second video format, represented as Enc2, to the reconstructed video sequence 140. The encoding process generates a second data unit 120.

[0061] The first video format differs from the second video format. These two video formats may correspond to two different video coding formats (e.g., ITU-T H.264, ITU-T H.265, or AV1). A video coding format can be described or defined by specifying its building blocks or the way these blocks exchange data with each other, such as the frequency domain transform (e.g., DCT, DST, DFT, wavelet transform) or coding method (e.g., entropy, Huffman, Lenper-Ziff, run-length, binary or non-binary arithmetic coding) to be applied to the pixel data. Alternatively, if the video coding format includes at least one parameter defined as variable, the first and second video formats can be two instances of the video coding format, where different parameter assignments have been applied to the two instances. For example, the instances may have different values ​​for parameters such as target bit rate, quantization step size, scaling factor, picture group (GOP) structure, number of reference frames, or search range for motion estimation. It should be understood that instantiation operations may include a template (model) that applies parameter assignments to computer-executable code such as an encoder process or decoder process, where the template represents the video coding format. In some cases, it is possible to modify the parameters of an existing instance of an encoder or decoder.

[0062] It should be understood that the first and second video formats result in virtually zero overlap between the first and second video data. That is, even if the first and second video data are representations of the same video sequence, the first video data does not substantially reproduce bit patterns in the second video data; to some extent, bit patterns do reappear, but these are finite-length segments, and the similarities are merely accidental. In particular, it should be understood that the second video data cannot be obtained by trimming or truncating portions of the first video data (e.g., dedicated trimmable or truncated portions). This means that transcoding from the first video format to the second video format typically requires an intermediate reconstructed video sequence that decodes the first video data (Dec1) into plaintext data represented as pixel values ​​or similar and is then fed into the second format encoder (Enc2).

[0063] exist Fourth step 216 In the process, the fingerprint of the first video data is calculated. Figure 1A The first fingerprint h 11 ,h 12 ,h 13 ,h 14 ,h 15 ) and the fingerprint of the second video data (second fingerprint h) 21 ,h 22 ,h 23 ,h 24 ,h 25The computation can be performed in ways known per se, including options reviewed in the preceding sections of this disclosure, such as with or without sequential linking, with or without salt, and using any suitable hash function.

[0064] exist Fifth step 218 In this process, a first bit string H1 is derived from the first fingerprint calculated in step 216, and a second bit string H2 is derived from the second fingerprint. As described in the previous subsection, bit strings H1 and H2 can be derived by concatenating fingerprints. In one example, assume a signature unit 130 with n1 first data unit 110 and n2 second data unit 120 (in... Figure 1A In the context of n1 = n2 = 5, the first bit string can be associated with n1 = n2 = 5. Given. Linking the first bit string to the second bit string is optional, and vice versa. Linking can include introducing a dependency between the first and second bit strings by linking the second bit string to the first bit string:

[0065]

[0066] Alternatively, the first bit string can be concatenated to the second bit string:

[0067]

[0068] Where h is the hash function. Although the first option can save some computational effort in evaluating the hash function, inserting h(H)... j ) and H j The same linking operation is achieved, and therefore the same level of data security is maintained. If the bit string is defined as a fingerprint of a combination of fingerprints, the linking can be ensured as follows:

[0069]

[0070] or

[0071]

[0072] This link allows the recipient of a signed video bitstream 100 to discover an attack in which an unauthorized third party has simultaneously replaced the first video data and the first bit string.

[0073] exist Sixth step 220In this process, one or more signature units 130 are formed. For this purpose, a digital signature of the bit string H1H2 is provided (e.g., s([H1,H2]), where s denotes a signature function), or a digital signature of the bit string H1H2 is provided (e.g., s(H1), s(H2)). The first digital signature s(H1) of the first bit string H1 can be independent of the second digital signature s(H2) of the second bit string H2, and vice versa. As described above, a digital signature can be provided using a private key located in a cryptographic element (not shown) in the apparatus performing this method 200; alternatively, the cryptographic element can be located in an external resource from which the apparatus requests a digital signature. Furthermore, the digital signature can be provided via symmetric key encryption.

[0074] like Figure 1B As shown, each signature unit 130 may include a first digital signature (H1) and a second digital signature (H2) derived from the bit strings H1H2 associated with the first and second video data. A signature unit 130 is typically associated with an entire GOP or multiple entire GOPs. In some embodiments, the interval between two consecutive signature units 130 may be at least one minute of playback time, preferably at least five minutes, and more preferably at least ten minutes. In ITU-T H.264 and H.265 formats, signature units 130 may be included as Supplemental Enhancement Information (SEI) messages, and in the AV1 standard, the signature may be included in the Metadata Open Bitstream Unit (OBU). As described above, the first and second digital signatures may be provided as a single digital signature.

[0075] In some embodiments (“documentary method”), such as Figure 1A As shown, the signature unit 130 further includes a first bit string H1 and a second bit string H2.

[0076] The signed video bitstream 100 provided by method 200 includes a signing unit 130, associated first video data (first video data unit 110), and optional additional types of units (e.g., dedicated metadata units). In at least some embodiments, the second video data does not form part of the signed video bitstream 100, but a receiver wishing to use the second video format must provide the video data in the second video format via transcoding. Therefore, the first video data is necessary for reconstructing the video sequence from the signed video bitstream 100. Furthermore, the second video data can be discarded upon completion of method 200, or even earlier, upon completion of the final steps (steps 214 and 216, respectively) using the reconstructed video sequence 140 and the second video data (second video data unit 120). The second video data can be discarded by being deleted from memory, cleared from memory, marked as rewritable, etc.

[0077] In some embodiments, the signed video bitstream 100 includes metadata identifying a second video format. As described above, the second video format can be identified based on a video encoding format (e.g., a standardized format such as ITU-T H.264) and / or based on the values ​​of one or more configurable parameters of the video encoding format to be used when instantiating the video encoding format.

[0078] In further development, the method 200 described above is extended with additional steps that allow the resulting signed video bitstream 100 to be transcoded (while maintaining verifiable authenticity) into a third video format and possibly other video formats. The additional steps include: encoding 214.1 the video sequence reconstructed from the first video data into third video data in a third video format; calculating 216.1 one or more third fingerprints of the third video data; and deriving 218. at least one third bit string H3 from the third fingerprint. Each signature unit 130 in the video bitstream 100 includes a first digital signature, a second digital signature, and a third digital signature, and optionally, also includes bit strings H1, H2, and H3. (The third video data is not present in the signed video bitstream 100.) The recipient of the signed video bitstream 100 is free to directly perform transcoding from the first video format to the third video format. Alternatively, in order to allow transcoding from the second video format to the third video format (and therefore from the first video format to the third video format via the second video format), step 214.1 should instead include encoding the video sequence reconstructed from the second video data in the third video format.

[0079] Methods for transcoding and verifying signed video sequences

[0080] Figure 3This is a flowchart of a method 300 for transcoding and verifying a signed video bitstream 100. Assume the signed video bitstream 100 includes first video data 110 in a first video format and one or more signature units 130, wherein the first video format is preferably a lossy format. Furthermore, each signature unit 130 includes a first digital signature s(H1) associated with the video data in the first video format and a second digital signature s(H2) associated with video data that can be obtained by transcoding to a second video format; Figure 4B The diagram illustrates a video bitstream 100 containing this content, where signature unit 130 has this content. Optionally, each signature unit 130 may further include a first bit string H1 and a second bit string H2, such that the first digital signature is a signature of the first bit string, and the second digital signature is a signature of the second bit string; in Figure 4A The diagram illustrates a video bitstream 100 containing this content, where signing unit 130 has this content (“Document Method”). By performing the method 200 described above, it is possible to obtain a video bitstream 100 with a signature of any of these types. However, since the source is generally undeterminable at the recipient's end in any case, from the perspective of this method 300, which can be applied to any signed video bitstream 100 with these characteristics, the source of the signed video bitstream 100 is irrelevant.

[0081] Method 300 can be performed, for example, in a video management system (VMS) or a playback device. In one contemplated use case, a signed video bitstream 100 in a first video format is stored in memory 590, and then it is retrieved from memory 590 at a later time and played back in a different second video format. Figure 5 and Figure 6The apparatus 500, shown in functional form, is suitable for performing transcoding method 300. As mentioned earlier, method 300 can also be performed jointly by two entities, such as a VMS (steps 316 and 318) and a playback device (steps 320, 322 and 324), or similarly by a streaming host and a playback device. The transcoding entity (VMS, streaming host, etc.) can transmit video data 120 to the second entity (playback device, etc.) in the form of a new signed bitstream (e.g., a file, a short stream, or a torrent) containing video data conforming to a second video format. Because the second entity receiving the new signed bitstream can autonomously verify the authenticity of the video data 120 in the second video using the signing unit 130, the second entity does not need to be in a trust relationship with the transcoding entity. One or more signing units 130 can be included in the new signed bitstream, or they can reach the second entity via different communication paths. For example, the new signed bitstream can include one or more signing units 130 from the original bitstream (i.e., these do not need to be processed) and the second video data 120 obtained through transcoding. The first video data 110 does not need to be included in the new signature bitstream; instead, it can be discarded.

[0082] In only some embodiments, steps 310, 312, and 314 form part of method 300. Because these steps are optional, they will be described separately below.

[0083] In the primary embodiment, method 300 is executed to reconstruct video sequence 140, for example, by feeding first video data to a decoder Dec1 configured for a first video format. Step 316 Begin. As described above, the decoder Dec1 preferably conforms to a standard or specification that has been pre-agreed between the sender and receiver, such that the current second step 312 is performed in accordance with the second step 212 of the method 200 that provides the signed video sequence 100.

[0084] Then, in the next Step 318 In the middle, video sequence 140 is reconstructed using a second video format encoding. This is in Figure 4A and Figure 4B The diagram below illustrates operation Enc2. The combination of operations Dec1 and Enc2 can be described as transcoding from a first video format to a second video format.

[0085] Next, in Step 320 In the middle, fingerprints The fingerprint is calculated using a hash function equivalent to the hash function h used at the sender. Because the first and / or second video data processed at the receiver may be authentic, this specification uses different symbols for the fingerprints calculated at the receiver and sender sides: respectively and h21 h 22 h 23 h 24 h 25 .

[0086] In another aspect of method 300 Step 322 In, bit string From the calculated fingerprint Export. (Among several other options, for example)

[0087]

[0088] In some embodiments of linking a second bit string to a first bit string, the fingerprint of the first video data This constitutes an additional input to the current step 322. More precisely, the fingerprint of the first video data is calculated and hashed into a quantity h(H1). This adds another layer of data security.

[0089] In other embodiments, alternatively, when the first bit string is linked to the second bit string, and when the signature unit 130 includes the first bit string H1 ( Figure 4A The receiver additionally verifies the first bit string H1 in the signature unit 130 and calculates the first bit string from the first video data in the signed video bit stream 100. Options. If the first bit string H1 being verified and the first bit string being calculated... If the comparison returns a true result, some further attack scenarios can be ruled out. For example, in an implementation where the execution of method 300 is divided between the transcoding entity and a second entity (e.g., the end user, playback device), the linking of the first bit string to the second bit string can be used to detect scenarios where the transcoding entity removes or adds video frames before an event in the video sequence to convey the false impression that the event occurred earlier or later. This setup becomes even more robust if the fingerprints are timestamped, for example, if they are provided as hashes salted with the recording time.

[0090] Use the exported bit string Then, the second video data is in the last Step 324 In this process, a second digital signature s(H2) is used for verification. To avoid any doubt, it should be noted that the verification of the second video data in step 324 is indirect, without any processing applied to the second video data itself.

[0091] In embodiments where the signature unit 130 does not contain the second bit string H2, the bit string derived by verifying s(H2) using the second digital signature is used. To perform step 324. For example, the derived bit string can be verified using a public key belonging to the same key pair as the private key used to generate the second digital signature s(H2). exist Figure 4B In this, this is achieved by deriving the bit string. The second digital signature s(H2) is fed to the cryptographic entity 401, which stores the public key and outputs a binary result W1 representing the verification result. In the case of a positive result, the signed video bitstream 100 can be consumed, or it can be isolated to prevent any further use or processing.

[0092] Alternatively, in an embodiment where the signature unit 130 includes a second bit string H2 (“Documentary Method”), step 324 may include verifying the second bit string (H2) from the signature unit 130 using the digital signature s(H2) and comparing the derived bit strings. The second bit string H2 is then verified. In the first sub-step, as described above, the second bit string H2 can be verified using the public key. Figure 4A This is illustrated in the diagram by feeding the second bit string H2 and the second signature s(H2) to the cryptographic entity 401, which stores the public key and produces the binary result V1. If the result V1 is true, the second bit string H2 is considered true, and the process proceeds to compare the derived bit string. The second bit string H2 is then verified. Conversely, if the result V1 is false, performing a comparison is meaningless; instead, it can be immediately concluded that the signed video bitstream 100 is invalid (box 328). Therefore, it is advantageous to perform the verification of the second bit string H2 using the digital signature s(H2) early in the execution process, such as before step 316, to avoid meaningless processing work. As for the comparison of the derived bit strings... The sub-steps of verifying the second bit string H2, as by Figure 4A As shown in function block 402, the comparison can be a bitwise equality check. If result V2 is true, it can be concluded that the signed video bitstream 100 is genuine with respect to that signing unit 130. For any other signing unit 130 in the signed video bitstream 100, repeat the relevant steps in steps 316, 318, 320, 322, and 324 above. If the result is positive for all signing units 130, the execution flow ends in box 326 (Bitstream Valid), otherwise it ends in box 328 (Bitstream Invalid).

[0093] In a further development of this method 300, the following steps are performed before step 316:

[0094] - Calculate one or more first fingerprints from the first video data of 310.

[0095] - Derive the first 312 bit string from the calculated first fingerprint. element

[0096] - Verify the first video data 110 in the 314-signed video bitstream 100 using the first digital signature s(H1).

[0097] Step 314 can include, for example, passing the first bit string of the first digital signature s(H1). Feeding to encrypted entity 401 to verify the derived first bit string using the first digital signature s(H1) Encryption entity 401 stores a public key associated with a private key, and generates a first digital signature s(H1) on the sender side using the private key. Alternatively, step 314 may include verifying the first bit string using the first digital signature s(H1) and comparing the derived bit strings if the signing unit 130 includes a first bit string related to video data of a first video format. The first bit string H1 is verified. (It should be noted that if the signature unit 130 includes the first bit string H1 and the second bit string H2, as well as a single digital signature of the two bit strings, then this verification of the first bit string H1 will essentially also be a verification of the second bit string H2. Therefore, the second bit string H2 does not need to be re-verified in step 324 [alternative implementations].)

[0098] If the first video data 110 is successfully validated, then proceeding to step 316 makes sense. However, in the case of a negative validation result for the first video data 110, the execution flow can proceed directly to the invalid conclusion (box 328), i.e., because the invalid first video data cannot be transcoded into valid second video data. This optional sequence of preceding steps can be a shortcut to the negative conclusion of method 300 as a whole, and thus can save transcoding work in the event of inevitable failure.

[0099] The aspects of this disclosure have been described above with reference to several embodiments. However, as will be readily understood by those skilled in the art, other embodiments besides those disclosed above are equally possible within the scope of the invention as defined by the appended claims. Furthermore, this disclosure can be readily extended beyond video data to include any type of data, such as documents, databases, images, audio, and immersive media, which exist in various encoding formats.

Claims

1. A method (200) for providing a signed video bitstream, the signed video bitstream being adapted to be transcoded from a first video format to a second video format, the method comprising: Obtain (210) lossy first video data (110); Reconstruct (212) the video sequence (140) from the first video data; The reconstructed video sequence is encoded (214) into second video data (120) in a second video format; Calculate (216) one or more first fingerprints (h) of the first video data 11 h 12 h 13 ...) and one or more second fingerprints (h) of the second video data 21 h 22 h 23 ,...); At least one first bit string (H1) is derived from the first fingerprint (218), and at least one second bit string (H2) is derived from the second fingerprint; and Provide (220) a signed video bitstream (100), the signed video bitstream comprising the first video data and one or more signature units (130), each signature unit comprising a first digital signature (s(H1)) of the derived first bit string and a second digital signature (s(H2)) of the derived second bit string and optionally including the derived first bit string and the second bit string.

2. The method according to claim 1, wherein, The first bit string is linked to the second bit string, or the second bit string is linked to the first bit string.

3. The method according to claim 1 or 2, wherein, The first digital signature (s(H1)) is independent of the second digital signature (s(H2)).

4. The method according to claim 1, wherein: The first video data and / or the second video data comprise a sequence of video data units; and The first fingerprint and / or the second fingerprint are each calculated for a video data unit (216) and are sequentially linked.

5. The method according to claim 1, wherein, The second video data is not present in the signed video bitstream.

6. The method according to claim 1, wherein, The first video format and the second video format are different video encoding formats, or the first video format and the second video format are different instances of the same video encoding format with different parameter assignments.

7. The method according to claim 1, wherein, The signed video bitstream further includes metadata identifying the second video format.

8. The method of claim 1, wherein the method provides a video bitstream suitable for transcoding such that the first video data and the second video data have substantially zero overlap.

9. The method of claim 1, further comprising: The video sequence reconstructed from the first video data or the video sequence reconstructed from the second video data is encoded (214.1) into third video data in a third video format; Calculate one or more third fingerprints of the third video data as described in (216.1); as well as Derive at least one third bit string from the third fingerprint (218.1).

10. The method according to claim 1, wherein, Each bit in the bit string is a combination of individual fingerprints or a combination of fingerprints.

11. The method according to claim 1, wherein, At least one of the fingerprints is a hash or salted hash of a video frame or a macroblock within a video frame.

12. A method for transcoding and verifying signed video bitstreams (300), in, The signed bitstream includes first video data (110) in a lossy first video format and one or more signature units (130), each signature unit including at least a first digital signature (s(H1)) and a second digital signature (s(H2)) and optionally including a first bit string (H1) and a second bit string (H2), wherein: The first digital signature is a first fingerprint (h) calculated from the first video data. 11 h 12 h 13 The signature of at least one first bit string derived from (, ...) and The second digital signature is derived from the second fingerprint (h) 21 h 22 h 23 The signature of at least one second bit string derived from (h, ...), the second fingerprint (h 21 h 22 h 23 , ...) is calculated from the second video data (120), which is obtained by reconstructing a video sequence (140) from the first video data using a second video format encoding. The method includes: Reconstruct (316) the video sequence (140) from the first video data; The reconstructed video sequence is encoded (318) into second video data (120) in the second video format; Calculate (320) one or more fingerprints (h) of the second video data 21 h 22 h 23 ,...); Derive the (322) bit string (H2) from the calculated fingerprint; and Verifying the second video data using the second digital signature (324) includes: verifying the derived bit string using the second digital signature, or verifying the second bit string (H2) in the one or more signature units using the digital signature (s(H2)) and comparing the derived bit string with the verified second bit string.

13. An apparatus (500) including a processing circuit (510) arranged to perform the method (200, 300) according to claim 1.

14. A non-transitory computer-readable storage medium storing instructions that, when executed by a computer, cause the computer to perform the method according to claim 1.

Images