Method for encoding a data stream, method for verifying a data stream, data stream, encoder, decoder

专利摘要:
AUTHENTICATION OF DATA FLOWS. The present invention relates to techniques for authentication and verification of data streams. Specifically, the invention relates to the insertion of identifiers into a data stream, such as a Dolby Pulse, AAC or HE AAC bit stream, and the authentication and verification of the data stream based on these identifiers. A method and system for encoding a data stream comprising a plurality of data frames are described. The method comprises the step of generating a cryptographic value from a number N of successive data frames and configuration information, wherein the configuration information comprises information for synthesizing the data stream. The method then inserts the cryptographic value into the data stream, subsequent to N successive frames of data.
公开号:BR112012002831B1
申请号:R112012002831-6
申请日:2010-08-06
公开日:2021-08-31
发明作者:Reinhold Boehm；Alexander Groeschel；Holger Hoerich；Daniel Homm；Wolfgang A. Schildbach；Michael Schug；Oliver Watzke；Martin Wolters；Thomas Ziegler
申请人:Dolby International Ab；
IPC主号:

专利说明:

TECHNICAL FIELD
[001] The present invention relates to techniques for authentication and verification of data flows. Specifically, the invention relates to the insertion of identifiers into a data stream, such as a Dolby Pulse, AAC or HE AAC bit stream, and the authentication and verification of the data stream based on that identifier. BACKGROUND
[002] With the increasing proliferation of digital radio and TV systems, data streams, comprising, for example, video data and/or audio data, are broadcast more and more frequently. In addition to the actual video and/or audio content, these data streams also comprise metadata, which provides, for example, receiver-side control of volume and dynamic range, as well as control of stereo remix and other aspects.
[003] In typical network scenarios, video frames and/or audio frames, and their associated metadata, are encoded in a broadcast head-of-network system. To that end, various encoding schemes such as Dolby E, Dolby Digital, AAC, HE AAC, DTS or Dolby Pulse can be used. Some of these coding schemes, notably Dolby Pulse, AAC and HE AAC, are particularly well suited for transmission over various transmission media, such as radio (FM frequency range, DVB/T, ATSC), twisted copper (DSL) , coaxial cables (eg CATV) or optical fibers. The receiver, for example a TV set, a radio receiver, a personal computer or a frequency signal box, has a suitable decoder and provides the decoded media stream. Furthermore, the receiver usually provides aspects, which are signaled through the metadata associated with the video and/or audio data.
[004] Examples of coding/decoding schemes are specified in ISO/IEC 14496-3 (2005) "Information technology - Coding of audio-visual objects - Part 3: Audio" for MPEG-4 AAC, and in the ISO standard /IEC 13818-7 (2003) "Generic Coding of Moving Pictures and Associated Audio Information - Part 7:Advanced Audio Coding (AAC)" for MPEG-4 AAC, which are incorporated by reference into this specification.
[005] Several techniques for authentication and/or identification are known. Some are based on embedding authentication data and/or information within encoded multimedia data. These techniques are also known as watermarking, and are designed specifically for copyright protection. Another technique for authentication and/or identification is digital signature, in which separate authentication data is provided with data files, such as emails, and used in a decoder for authentication and identification purposes.
[006] For a receiver of data streams to be able to identify the encoder of the data stream, it is desirable to provide a means of authentication along with the data stream. It can also be beneficial to check the integrity of the data stream. Furthermore, it can be beneficial to ensure the correct configuration of the receiver with regard to the data stream that is to be reproduced or processed. Furthermore, it can be beneficial to allow the implementation of services with built-in value or special control functionalities for the data flows, which have been properly authenticated and/or verified. These and other aspects are addressed in this patent document. SUMMARY
[007] The proposed method and system make use of an identifier, which can be provided as metadata within a data stream. These data streams are preferably data streams that are transmitted over a wired or wireless transmission medium, but the data streams may also be provided on a data storage medium such as a CD, DVD or memory instant. The identifier allows a decoder, on the receiving side, to check whether or not a data stream, which it receives, is from a secure encoder, that is, a legitimate encoder, on the transmitting and/or encoding side. This check can be particularly beneficial if a decoder supports different types of encoders. By way of example, a Dolby Pulse decoder may be compatible with a HE-AAC version 2 encoder. In this scenario, it may be desirable to allow a Dolby Pulse decoder to provide certain non-standard and non-mandatory aspects only if the traffic, ie, the data streams, if they originate from suitable Dolby Pulse encoders. By using this identifier, a Dolby Pulse decoder will be able to differentiate between a data stream or a bit stream, generated by a suitable Dolby Pulse encoder, and a data stream or bit stream, generated by a according to HE-AACv2. As such, it can be guaranteed that additional aspects, for example the use of dynamic metadata, are only considered by the decoder if the data stream originates from a secure encoder. By doing this, the correct functioning of additional aspects can be guaranteed.
[008] Another benefit of the identifier is that it can allow a decoder to verify that a bitstream has been correctly received, and that the bitstream has not been modified or tampered with during transmission. In other words, the identifier allows the decoder to verify the integrity of the received bit stream.
[009] Furthermore, the identifier can be used to ensure that the decoder is set to the correct processing, eg playback, setup, to properly synthesize the media/multimedia signal. By way of example, this setting can be directed to the sampling frequency at which the media signal is reproduced. The setup can also be directed towards setting up channels, eg 2 stereo channels, with different surround sound settings, etc., which are to be used for reproduction. Another configuration aspect can be directed to frame length, for example 1024 sample frames or 960 sample frames in the case of AAC, which is used in the particular coding scheme.
[0010] Apart from the identification and authentication purposes of the encoder, the identifier can be used to verify the authenticity of the data stream payload. To that end, the identifier must not be easily forgettable, and a manipulation of the protected segment must be identifiable. Furthermore, it is desirable for a decoder to identify the authenticity of a bit stream at relatively short time intervals. It is preferable that the maximum time, until a decoder or decoding device is able to identify an authentic bit stream, when the continuous stream does not exceed 1 second. Furthermore, the complexity introduced by the identifier verification in the decoder must be kept low, that is, the increase in decoder complexity must be negligible. Finally, the transmission overhead, introduced by the identifier, must be kept low.
[0011] According to an embodiment, the benefits mentioned above can be achieved by making use of a cryptographic value or identifier, originated according to the method described below. The identifier can be determined, in the encoder, by applying a unique mode function to a group of one or more data frames. A frame typically comprises data associated with a certain segment of an audio and/or video stream, for example a segment comprising a certain number of media streams. By way of example, a frame of an audio stream can comprise 1,024 samples of audio data and corresponding metadata.
[0012] As mentioned above, for the purpose of determining an identifier, a certain number of frames is grouped. The number of frames in each group can be selected by the encoder, and is typically not known in advance by the decoder. The single-mode function is preferably a cryptographic hash function (hash message authentication code) HMAC-MD5, although other hash functions, such as a SHA-1, can be used in place of MD5. A possible criterion for selecting a suitable cryptographic hash function might be its size, which should be kept small to reduce the overhead required for transmission. The size of a cryptographic hash function is typically given by its number of bits.
[0013] Once an identifier, for a group of frames, has been calculated by using, for example, the HMAC-MD5 procedure, it can be associated with, for example, inserted into, a frame of the next group of frames. By way of example, the identifier can be written in a data field or in a syntactic element of the frame. Preferably, the identifier is inserted into the first name of the next frame group. This allows the identifier to be calculated as a single pass operation, without introducing added latency to the encoder/decoder, which is particularly beneficial for real-time media transmission. The data stream comprising the identifier can then be transmitted to the corresponding receivers/decoders.
[0014] At a receiver, the identifier entered can be used for purposes of identification, authentication, verification and/or configuration of the encoder. The receiver typically comprises a decoder, which can synchronize to a group of frames, i.e. can determine which frames comprise an identifier. Based on the distance between two successive frames, which comprise an identifier, the number of frames per group of frames, which were used to calculate the identifier, can be determined. In other words, this can allow the decoder to determine the length of the group of frames, without notification from the corresponding encoder.
[0015] The decoder can calculate the identifier for a group of received frames. The identifiers, which are calculated based on the group of frames received, can be referred to as verification identifiers. If identifiers are assumed to be inserted into the first frame of a successive frame group, then each frame group will start with a first frame, which comprises an identifier for the previous frame group, and will end with the directly preceding frame. the next frame, which comprises an identifier for the present group of frames. For the present group of frames, a verification identifier can be calculated according to the methods described above.
[0016] In another step, the decoder can extract the identifier, transmitted by the encoder of the respective frame of the subsequent frame group. Again, if the identifiers are inserted in the encoder into the first frame of a group of successive frames, then also the receiver extracts the identifier from that first frame. This identifier, which has been retrieved from the data stream, can be compared with the verification identifier, that is, the identifier which is calculated by the decoder based on the received data stream. If both identifiers are the same, the decoder can typically assume that no error occurred during transmission, the frame group was received intact, the frame group was not modified during transmission, and the frame group is one secure and/or legitimate encoder. Additionally, if both identifiers are the same, the decoder may select to allow one or more specific encoding/decoding aspects or enhancements, which are not enabled when an arbitrary bitstream is selected, to be decoded. By way of example, additional services can be enabled if the decoder identifies a specific Dolby Pulse bitstream, whereas these built-in services will not be available for a standard HE-AAC version 2 encoded bitstream. the decoder can be enabled to decode the standard HE-AAC version 2 encoded bitstream without, however, using the additional services.
[0017] It should be noted that, furthermore, the identifier may be allowed to ensure that the proper setting, to correctly decode and/or reproduce the media stream, is set in the decoder. In these cases, an identical verification identifier and transmitted identifier will indicate that the decoder uses the correct configuration settings.
[0018] If, on the other hand, the identifiers, that is, the verification identifier and the transmitted identifier, are not the same, then the decoder will know that an error occurred during transmission, the group of frames was not received intact, the framegroup was modified during transmission, or the framegroup was not a secure encoder. In such cases, the decoder can be disabled entirely, or, alternatively, specific features or enhancements can be disabled.
[0019] It should be noted that the identifier can also be used to inform the decoder that the wrong configuration settings have been established. In such cases, a mismatch between the check identifier and the transmitted identifier may be due to the decoder using the wrong configuration settings, even though the frame group is received intact and from an insecure encoder. It can be considered that, in these cases, the decoder can be operative to modify its configuration settings and determine the corresponding verification identifiers, until the verification identifier is equal to the transmitted identifier. This will allow the decoder to actually adjust its configuration to the requirements of the received bitstream.
[0020] Below, different aspects of the proposed method are described. According to a first aspect, a method for encoding a data stream comprising a plurality of frame groups is described. Data streams can be audio, video and/or media and multimedia streams. In particular, data streams can be Dolby Pulse, AAC or HE AAC data streams. Data streams are typically organized into data frames, which comprise a certain number of data samples and cover a certain segment of the data stream. By way of example, a frame may comprise 1,024 samples of an audio signal, sampled at a sampling rate of 44.1 kHz, i.e. it covers a segment of about 23 ms. It should be noted that samples can be encoded at constant or variable bit rates, and the actual number of bits within a frame can vary.
[0021] The method may comprise the step of grouping a number N of successive data frames to form a first message. The number N of successive data frames is typically selected with regard to data rate overhead considerations. Usually, the extra code decreases with increasing number N. N is preferably greater than one. Typical values for N are around 20. In a preferred embodiment, N can be selected so that N successive frames cover 0.5 second of a corresponding signal, when reproduced in a corresponding decoder, with a suitable decoder configuration . It should be noted that the grouping step can comprise the concatenation of the N successive frames in the natural order, that is, continuous flow.
[0022] In another step, the first message can be grouped with the configuration information, to form a second message. This configuration information comprises information external to the data stream, and is typically related to the data stream, in particular, information for synthesizing the data stream on one side of the receiver. The configuration information can comprise information regarding the settings of the respective receiver and/or decoder, which can be used to process the data stream. As this configuration information is not typically transmitted or included in the data stream, it can also be referred to as out-of-band data. This is opposite to data flow, which can also be referred to as in-band data.
[0023] Configuration information can be grouped with the first message in various ways. They can be concatenated with the first message, that is, they can be placed at the beginning and/or at the end of the first message. Configuration information can also be placed in certain positions within the first message, for example, between some or all of the successive frames.
[0024] Typical examples for configuration information comprise an indication of a sampling rate, which was used to sample the associated analog media stream. The configuration information may also comprise a channel configuration of an audio coding system, such as a mono, two stereo channel, or 5.1 surround channel configuration. It may also comprise an indication of the number of samples in a data frame, for example 960, 1024 or 2048 samples per data frame.
[0025] The method further comprises the step of generating a cryptographic value of the first and/or second message. The cryptographic value can also be referred to as an identifier. The cryptographic value can be generated using a principal value and a cryptographic hash function. In particular, the cryptographic value can be generated by calculating an HMAC-MD5 value for the first and/or second message. Furthermore, generating the cryptographic value may comprise truncating the HMAC-MD5 value, for example truncating to 16, 24, 32, 48 or 64 bits. This can be beneficial in view of reducing the overhead required for the cryptographic value in the data stream.
[0026] Furthermore, the method comprises inserting the graphic crypto value in the data stream, subsequent to the N successive data frames. Preferably, the cryptographic value is inserted in the first frame, following the N successive data frames, to allow for quick decoding and encoder authentication and verification in a corresponding decoder. It may also be beneficial to insert a sync indication, subsequent to the N successive data frames, where the sync indication indicates that the cryptographic value has been entered. This synchronization indication can be placed in the vicinity of the cryptographic value, to allow convenient extraction of the cryptographic value to a corresponding decoder.
[0027] In an exemplary embodiment, the data stream is an MPEG4-AAC or MPEG2-AAC stream, and the cryptographic value is inserted as a data stream element <DSE>. This <DSE> dataflow element can be inserted at the end of a frame, before a <TERM> element. Furthermore, the contents of this <DSE> data stream element can preferably be aligned to a data stream byte boundary, to simplify the extraction of the <DSE> data stream element, and in particular , the cryptographic value and/or the synchronization indication, to a corresponding decoder.
[0028] It should be noted that the step of generating a cryptographic value can preferably be conducted iteratively on the individual frames of a group of N successive frames. To that end, an intermediate cryptographic value can be generated for each of the N successive frames, using a starting state. The starting state can be the intermediate cryptographic value from the previous iteration. By way of example, an intermediate cryptographic value can be generated for the first frame. This intermediate cryptographic value can then be used as the starting state for generating an intermediate cryptographic value from the second frame. This process is repeated until an intermediate cryptographic value of Frame # is generated. This last intermediate cryptographic value typically represents the cryptographic value for the group of N successive frames. To consider the configuration information, the starting state of the first iteration can be an intermediate cryptographic value of the configuration information.
[0029] In a preferred embodiment, the cryptographic value of a block of N successive data frames is generated in the block of N successive data frames comprising the cryptographic value of the previous block of N successive data frames. By doing this, a stream of interconnected cryptographic values can be generated.
[0030] According to another aspect, the method can comprise the step of interacting with a video and/or audio encoder of the data stream. This can be implemented by conducting video and/or audio encoding as well as generating the cryptographic value in an integrated manner. In particular, the interaction between the video and/or audio encoder of the data stream and the generation of the cryptographic value can be directed towards a maximum bit rate setting for the video and/or audio encoder, so that a bit rate of the data stream comprising the cryptographic value does not exceed a predetermined value. This can be particularly beneficial if the encoding/decoding of the associated data stream sets an upper bit rate threshold for a full data stream.
[0031] According to another aspect, a method for verifying a data stream in a decoder and/or receiver is described. It should be noted that the methods and systems described can be applicable in the context of transmitted data streams as well as data streams provided on a storage medium. As described above, the data stream typically comprises a plurality of data frames, and a cryptographic value, associated with a number N of preceding successive data frames. Reference is made to the consideration presented in this document, notably in relation to possible values for N and the structure of the data flow and its tables.
[0032] The method comprises the step of extracting N successive data frames to form a first message. The method also comprises the step of determining the value of N. This can be performed on a data stream, which comprises a plurality of N successive data frames and associated cryptographic values. If N successive data frames are referred to as a frame group, that data stream typically comprises a plurality of frame groups and a cryptographic value associated with each frame group. In such cases, the number N can be determined as the number of frames between two successive cryptographic values.
[0033] It should be noted that the present frame group, which is used to calculate a second cryptographic value, may comprise the cryptographic value of the preceding frame group. Alternatively, the cryptographic value of the preceding frame group and any associated synchronization indication and/or syntactic element may first be removed from the present frame group, prior to calculating the second cryptographic value. This solution may be preferable to prevent propagation variations and discrepancies from one group of frames to the next.
[0034] The method may further comprise the step of grouping the first message with the configuration information to form a second message, wherein the configuration information typically comprises information external to the data stream, such as to synthesize the data stream. Dice. The grouping step and the different aspects regarding configuration information were described above. These aspects are equally applicable to the decoder.
[0035] The method continues by generating a second cryptographic value of the first and/or second message, extracting the cryptographic value from the data stream and comparing the cryptographic value with the second cryptographic value. The second cryptographic value may also be referred to as the verification cryptographic value or the verification identifier.
[0036] It should be noted that the second cryptographic value can be generated in an iterative manner, as described in the context of generating the cryptographic value.
[0037] In a preferred embodiment, the cryptographic value was generated in a corresponding encoder and/or transmitter of the N successive data frames and configuration information, according to a method corresponding to the method used to generate the second cryptographic value. In other words, the method for generating the cryptographic value in the corresponding encoder conforms to the method for generating the second cryptographic value in the decoder. In particular, the cryptographic value and the second cryptographic value are generated by using a single principal value and/or a single cryptographic hash function.
[0038] Furthermore, the set of N successive frames used to generate the cryptographic value in the encoder corresponds to the set of N successive frames to generate the second cryptographic value in the decoder. As mentioned above, the cryptographic value and the second cryptographic value can be determined in the set of N successive frames, which comprise or do not comprise the cryptographic value from the preceding set of N successive frames. The same rule must be applied in the encoder and in the decoder.
[0039] Even though the sets of frames in the encoder and decoder are identical, it should be noted that the content of frames in the encoder and decoder may differ, for example, due to modifications incurred during frame transmission or due to to errors in the data stream storage medium.
[0040] According to another aspect, the method may comprise the steps of setting a flag, if the cryptographic value corresponds to the second cryptographic value, and/or of providing a visual indication in the receiver and/or decoder, if the flag is set. Analogously, the flag and/or visual indication may be removed if the cryptographic value does not match the second cryptographic value, or if no cryptographic value can be extracted from the data stream. This can be beneficial in providing a decoder user and a viewer/listener of the data stream with information about the authenticity of the data stream.
[0041] According to another aspect, a data stream comprising a cryptographic value, generated and entered according to the methods described in this patent document, is described.
[0042] According to another aspect, an encoder operable to encode a data stream comprising a plurality of data frames is described. The encoder is operative to carry out the method steps described in this patent document. In particular, the encoder may comprise a processor operative to assemble a number N of successive data frames to form a first message, where N is greater than one, to assemble the first message with configuration information, to form a second message, wherein the configuration information comprises information external to the data stream, such as to synthesize the data stream, to generate a cryptographic value of the second message, and insert the cryptographic value into the data stream, subsequent to the N data frames successive ones.
[0043] According to another aspect, a decoder operative to verify a data stream comprising a plurality of data frames and a cryptographic value associated with a number N of successive data frames, where N is greater than one, is described. The decoder is operative to carry out the method steps described in this patent document. In particular, the decoder may comprise: a processor operable to: extract the N successive data frames to form a first message; to group the first message with configuration information; to form a second message, wherein the configuration information comprises information to: synthesize the data stream; to generate a second cryptographic value from the second message; to extract the cryptographic value from the data stream; and to compare the cryptographic value with the second cryptographic value.
[0044] According to another aspect, a software program is described. The software program is adapted to run on a processor and to carry out the process steps described in this patent document when carried out on a computing device.
[0045] According to another aspect, a storage medium is described. The storage medium comprises a software program adapted for execution on a processor and for carrying out the method steps described in this patent document when conducted on a computing device.
[0046] According to another aspect, a computer program product is described. The computer program product comprises executable instructions for carrying out the method steps described in this patent document when executed on a computer.
[0047] According to another aspect, a frequency signal box, a portable electronic device (eg a mobile phone, a PDA, a smart phone, etc.) or a computer (eg a desktop computer , a laptop, etc.) to decode a received data stream is described. The data stream can comprise an audio signal. The frequency signal box comprises a decoder, in accordance with the aspects described in the present patent document.
[0048] According to another aspect, a broadcast system for transmitting a data stream is described. The data stream can comprise an audio signal. The broadcast system preferably comprises an encoder, in accordance with aspects described in this patent document.
[0049] According to another aspect, a method for concatenating a first and a second bit stream at a splice point is described. Each of the two bitstreams may comprise a plurality of data frames and a cryptographic value associated with a certain number of data frames. The first bitstream may comprise a cryptographic value for each N1 successive frames, while the second bitstream may comprise a cryptographic value for each N2 successive frames. The numbers N1 and N2 can be identical, i.e. the two bitstreams have the same cryptographic repetition period, or the numbers N1 and N2 can be different, i.e., the frame numbers, after the cryptographic values have been included. in bitstreams, they are different.
[0050] The concatenation method comprises the step of generating a concatenated bitstream of the first and second bitstream, wherein the concatenated bitstream comprises at least a part of the plurality of data frames of the first and second bitstream . In other words, the second bitstream or a part of it is stuck, at the splice point, to the first bitstream or a part of it.
[0051] The concatenated bit stream comprises cryptographic values generated and inserted according to the methods described in this patent document. Advantageously, the cryptographic values in the concatenated bitstream evenly cover the splice point so that no interruption of bitstream authenticity is noticeable in a receiver/decoder. This can be achieved by explicitly generating new cryptographic values for the concatenated bitstream after the splice point.
[0052] New cryptographic values can be generated at least for a certain number of successive frames, in a section of the concatenated bit stream, starting at the splice point. In some cases, the cryptographic values from the second bitstream can be reused and copied into the concatenated bitstream, after the section in which new cryptographic values have been added. This applies in particular when the cryptographic value of the previous frame group, which is included in the first frame of the next group, is not considered for the calculation of the cryptographic value of the next group, and the groups can be manipulated independently, i.e. variations in cryptographic values are not propagated from one group to the next.
[0053] Explicit generation of cryptographic values, according to the methods described in this patent document, can be particularly beneficial in the boundaries between the first bit stream and the second bit stream, that is, for the final frames of the first bitstream and for the primary frames of the second bitstream, which are included in the concatenated bitstream. In general, In general, when splicing two bitstreams, the number of ending frames of the first bitstream is typically less than or equal to N1, and/or the number of frames taken from the second bitstream, before the first. cryptographic value to be included, is typically less than or equal to N2. In other words, the splice point is not typically positioned on the group boundaries of the first and second bit streams.
[0054] According to an aspect of the concatenation or splicing method, a new cryptographic value is generated for the end frames of the first bit stream and inserted into the frame of the concatenated bit stream, which is the first frame taken from the second bit stream. bits. This new cryptographic value is considered to "complete" the first bitstream. The new cryptographic values can then be generated for the second bitstream and included in the concatenated bitstream at the appropriate positions. This is particularly useful if, without the added cryptographic value, inserted in the first frame, taken from the second bitstream, the number of frames, between the last cryptographic value, generated for the frames of the first bitstream, and the first cryptographic value , generated for the frames of the second bitstream, will exceed a maximum number allowed by the system.
[0055] In the case in which the splice point is not aligned with the groups of frames of the first and second bit streams, the splicing method can generate a cryptographic value for a mixed group, comprising frames taken from the first and second bit streams. bits. As already mentioned, cryptographic values are typically included in the next frame, after the group of frames used to calculate the respective cryptographic value.
[0056] According to another aspect, a splice and/or a broadcast head is(are) described. Such splice and/or broadcast headband is (are) operative to concatenate a first and a second bit stream, each comprising a plurality of data frames and cryptographic values associated with a certain number of data frames. Dice. The device may comprise a decoder having any combination of features described in this patent document. This decoder can be used to decode the ending frames of the first data stream, the primary frames of the second bitstream, and the associated cryptographic values. The splice(s) and/or broadcast head(s) may further comprise an encoder having any combination of features described in the present patent document. The encoder can be used to encode the ending frames of the first bitstream and the primary frames of the second bitstream. Furthermore, the splice and/or broadcast head(s) may comprise a forwarding unit for forwarding frames and associated cryptographic values of the first and second bit streams, which are not decoded and encoded. In other words, the forwarding unit can simply copy or forward or drive through the associated cryptographic frames and values into the concatenated bitstream.
[0057] It should be noted that the amender may also be operative to decode and encode the complete data streams, that is, to decode the cryptographic values of an incoming data stream, and generate cryptographic values for the incoming data stream. exit. This can be beneficial to generate a continuous bitstream interlocking of cryptographic values. Indeed, a plurality of bitstreams can be decoded and a concatenated bitstream, comprising parts of the plurality of bitstreams, can be encoded with continuously interconnected cryptographic values. As such, a receiver of the concatenated bitstream will regard the concatenated bitstream as a bitstream originating from a single insecure encoder.
[0058] It should also be noted that for the purpose of decoding and/or encoding bit streams comprising cryptographic values, the splicer may not need to be aware of the associated decoder/encoder of the data stream. By way of example, the splice does not need to be enabled to conduct HE-AAC decoding/encoding, to extract and/or generate the cryptographic values from the data streams. In some situations, for example, when a new cryptographic value is inserted into a frame that previously had no cryptographic value, decoding and subsequent recoding of the data stream may be necessary to make room in the bitstream for the new cryptographic value. , in particular, to satisfy the bitstream requirements.
[0059] It should be noted that the methods and systems, including the preferred embodiments, as described in the present patent application, can be used alone or in combination with the other methods and systems described in this document. Furthermore, all aspects of the methods and systems described in this patent application may be arbitrarily combined. In particular, aspects of the claims may be combined with each other in an arbitrary manner. Also, it should be noted that the order of method steps can be varied. DESCRIPTION OF THE FIGURES
[0060] The invention is explained below in an exemplary manner, with reference to the attached drawings, in which:
[0061] Figure 1 illustrates an exemplary method for determining an identifier according to the invention;
[0062] figures 2a and 2b show flowcharts of an exemplary method for generating and inserting an identifier in the encoder;
[0063] Figure 3 shows a block diagram of the authentication and verification steps conducted in the decoder;
[0064] Figure 4 illustrates an exemplary embodiment of an encoder and a decoder;
[0065] Figure 5 illustrates an example for the use of an identifier within a broadcast system; and
[0066] figures 6 and 7 illustrate examples of splicing bit streams to form a concatenated bit stream.
[0067] The following embodiments are described by way of example and should not be limited to the scope of this patent document. The invention will be described in the context of AAC (Advanced Audio Coding) and in particular MPEG-2 AAC and MPEG-4 AAC. It should be noted, however, that the invention can also be applied to other media encoding schemes, notably audio, video and/or multimedia encoding schemes. What's more, it can be applied in a splice, providing combined bitstream from a plurality of encoders.
[0068] Figure 1 illustrates a bitstream 100 and a method of how an identifier is determined for that bitstream 100. Examples for these bitstreams are video and/or audio bitstreams with AAC, HE- AAC (Advanced High Efficiency Audio Coding), Dolby Pulse, MPEG-4 AVC/H.264, MPEG-2 Video or MPEG-4 Video, as an associated encoding/decoding. These encodings/decodings and their formats are defined, for example, in the ISO/IEC 14496-3 specification for MPEG-4 AAC, in the ISO/IEC 13818-7 specification for MPEG-2 AAC, in the ISO/IEC 14496-10 specification for MPEG-4 AAC/H.264, the ISO/IEC 13818-2 specification for MPEG-2 Video, and the ISO/IEC 14496-2 specification for MPEG-4 Video. These specifications are incorporated by reference. In these encodings/decodings, the data streams are arranged in so-called frames, where the frames comprise a certain number of media samples. Different encodings/decodings can use different number of samples per frame. Typical examples are 960, 1,024, or 2,048 samples per frame.
[0069] In addition to the effective media data, the frames can also comprise the so-called metadata, which can carry additional control information, for example, in volume or dynamic program variation.
[0070] Figure 1 shows a succession of frames 101, 102, 103 to 106. The time axis goes from left to right, so that frame 101 is processed before frame 106. As described above, each frame can understand media data and other metadata. The structure of each frame and the possible fields or data elements it can understand are defined by the associated coding scheme. By way of example, an MPEG-4 AAC frame or an MPEG-2 AAC frame may comprise audio data, for a time period of 1024 or 960 samples, relative information and other data. Its syntax and structure are defined in sections 4.4 and 4.5 of the ISO/IEC 14496-3 FOR MPEG-4 AAC specification and sections 6 and 8 of the ISO/IEC 13818-7 specification mentioned above for MPEG-2 AAC. These sections are incorporated by reference.
[0071] An MPEG-4 AAC or MPEG-2 AAC frame may comprise different syntactic elements, such as: . a single_channel_element(), abbreviated as SCE, which is the syntactic element of the bit stream containing encoded data for a single audio channel; . a channel_pair_element(), abbreviated as CPE, which is the syntactic element of the payload of bitstreams containing data for a pair of channels; . a coupling_channel_element(), abbreviated as CCE, which is the syntactic element that contains audio data for a coupling channel; . an lfe_channel_element(), abbreviated as LFE, which is the syntactic element that contains a low-frequency sampling enhancement channel; . a program_config_element(), abbreviated as PCE, which is the syntactic element that contains program configuration data; . a fill_element(), abbreviated as FIL, which is the syntactic element that contains fill data; . a data_stream_element(), abbreviated as DSE, which is the syntactic element that contains auxiliary data; and . a TERM syntactic element, indicating the end of a raw data block or frame.
[0072] These syntactic elements are used within a frame or raw data block, to specify the media data and related control data. By way of example, two frames of a mono audio signal can be specified using the syntactic elements <SCE><TERM><SCE><TERM>. Two frames of a stereo audio signal can be specified by the syntactic elements <CPE><TERM><CPE><TERM>. Two frames of a 5.1 audio signal can be specified by the syntactic elements <SCE><CPE><CPE><LFE><TERM><SCE><CPE><CPE><LFE><TE RM>.
[0073] The proposed method groups a certain number N of these frames and thereby forms frame groups 111, 112 and 113. Figure 1 shows a complete frame group 112, comprising N = 5 frames 103 to 105. The five frames of frame group 112 are concatenated to form a first message.
[0074] Using a cryptographic hash function H(.) and a "secret" key K, which is typically added to the right with extra zeros to the block size of the hash function H(.), a hash message authentication code (HMAC) of the first message, can be determined. It will be specified that the sign | denote a concatenation and the sign Φ denotes an exclusive one, and the outer padding opad = 0x5c5c5c...5c5c and the inner padding ipad = 0x363636...3636 are constants of the block size length of the hash function H(.), then the HMAC value of the first message will be written as HMAC (m) = H((KΦopad)|H((kθipad)|m)),
[0075] where m is a message, also referred to in this case as the first message. The block size, used with the MD5 or SHA-1 hash functions, is typically 512 bits. The output size of the HMAC operation is equal to that of the associated “hash” function, ie 128 bits in the case of MD5, or 160 bits in the case of SHA-1.
[0076] The HMAC value of the first message, that is, the HMAC value of the concatenated frames 103 to 105 of the frame group 112, can be used as the frame group identifier 112. To reduce the identifier length, the HMAC value it can be truncated, for example, truncated to 16, 24, 32, 48 or 64 bits. It should be noted, however, that this truncation operation typically affects the security of the hash message authentication code. As the identifier is inserted into the data stream, the proposed method preferably uses a truncated version of the HMAC value as the identifier.
[0077] As shown in Fig. 1, the identifier 122 of the frame group 112 is inserted into a frame of the following frame group 113. Preferably, the identifier 122 is inserted into the first frame 106 of the successive frame group 113. In a similar manner, an identifier 121 has been determined for the preceding frame group 111 and inserted into the first frame 103 of the frame group 112.
[0078] It should be noted that the identifier 122 of the frame group 112 can be calculated based on a first message m, which comprises the identifier 121 of the previous frame group 111, or it can be calculated based on a first message m , which does not comprise identifier 121 of previous frame group 111. In this case, the information regarding the identifier 121 will need to be removed from the first message m, before determining the identifier 122. One will need to make sure that the encoder and decoder apply the same method to define the first message m . In a preferred embodiment, the identifier 122 is determined based on a first message m, which comprises the identifier 121 of the previous frame group 111. By doing this, the identifiers can be linked continuously, and in this way a linked bitstream can be created that cannot be modified, for example, by modifying or replacing certain groups of frames in the bitstream. . Consequently, the authenticity of the complete data stream or bit stream can be guaranteed. On the other hand, it is still guaranteed that a receiver can resynchronize to a partially corrupted bit stream, even if the identifiers are interlinked.
[0079] In a preferred embodiment, the identifier is placed in a single data_stream_element (data stream element)(), abbreviated as <DSE>, and defined in ISO/IEC 14496-3, table 4.10 for MPEG-4 AAC, or defined in ISO/IEC 13818-7, table 24 for MPEG-2 AAC, which are incorporated by reference. To facilitate a decoder synchronization, an AAC frame should only comprise a data_stream_element() <DSE>, having an identifier, so that the decoder can determine the length of a group of frames, as the distance between two received identifiers. In other words, an AAC frame may comprise several data_stream_element() <DSE>, but it must comprise only one data_stream_element() <DSE>, which comprises an identifier. In a preferred embodiment, the location of the <DSE> is at the end of the AAC frame, before the <TERM> element.
[0080] To allow quick tag extraction, the byte alignment aspect of DSE can be used. To that end, the DSE typically comprises a field or a bit, which indicates that the data comprised in the DSE is byte-aligned. This tells a decoder that the actual DSE data starts at a bit position at the beginning of a byte.
[0081] A bit stream or data stream can comprise multiple <DSE>. In order to distinguish one <DSE> from another, each <DSE> typically includes an element_instance_tag, as defined for MPEG-4 AAC in ISO/IEC 14496-3, section 4.5.2.1.1, and for MPEG -2 AAC in ISO/IEC 13818-7, section 8.2.2, both being incorporated by reference. It should be noted that the value of the element_instance_tag of the data_stream_element() comprising the identifier is not limited to a specific value, ie the generic rules of the ISO/IEC standards apply. In other words, there are preferably no special rules for the element case flag for a <DSE>, containing a transmitted identifier in addition to those set out for MPEG-4 AAC in ISO/IEC 14496-3 and for MPEG- 2 AAC in ISO/IEC 13818-7.
[0082] In analogy to the examples of possible streams shown above, a data stream for a 2-channel audio program can comprise the syntactic elements <CPE><FIL><DSE><TERM><CPE><FIL> <DSE><TERM> A 2-channel audio program with SBR (Band Spectral Replication) can comprise the syntactic elements <CPE><SBR(CPE)><FIL><DSE><TERM><CPE><SBR( CPE)><FIL>< DSE><TERM>..., where <SBR(CPE)> is a syntactic element specific to SBR. A 5.1-channel audio program can be made up of the syntactic elements <SCE><CPE><CPE><LFE><DSE><TERM><SCE><CPE><CPE><LF E><FIL><DSE> <TERM>
[0083] In a preferred embodiment, the identifier field placed in the <DSE> element may comprise an identifier_sync field and an identifier_value field. The identifier_sync field can be used to allow quick identification, based on the fact that the particular <DSE> element comprises an identifier. By way of example, the encoder can set its field to a predefined value, e.g. a binary template, to indicate that the <DSE> element comprises an identifier field. The decoder can use this field to check the availability of the identifier value. In other words, the decoder is informed that the received data stream comprises an identifier, which can be used for the authentication, verification and possibly configuration purposes mentioned above.
[0084] In a preferred embodiment, the identifier_value field comprises the value of the identifier that was determined as described in this document. The field comprises the required number of bits for the identifier, that is, for the truncated version of the HMAC value. As described above, the identifier typically covers N, where N > 1, the AAC frames and each AAC frame No. comprises an identifier, i.e., comprises a <DSE> element, which comprises an identifier element, as described above . Typically, it is the encoder that decides the number N of AAC frames covered. The decoder is able to determine this value by the distance in frames between the AAC frames, comprising the corresponding identifiers.
[0085] As described above, the identifier can also be used to ensure that the decoder uses the correct configuration settings. To that end, the identifier can be generated based on an extended message, which not only comprises the concatenation of N successive frames, but which also comprises configuration data. In other words, the first message, which comprises N successive frames as described above, can further comprise configuration data. Such configuration data may comprise a Sampling Frequency Index, i.e. an indication of the associated sampling frequency of the audio signal, a Channel Configuration, i.e. an indication of the channel configuration used, and a Frame Length Flag, i.e. an indication of the frame length used. Other configuration parameters are also possible.
[0086] These parameters, ie AAC sampling rate (core) or "sampling frequency index", channel setting and AAC transform length indication, or "frame length flag" can be used to form a configuration_word. This configuration_word can also comprise padding bits, to set it to a predetermined size.
[0087] In a preferred embodiment, the parameters "sampling Frequency Index" and "Channel Configuration" have the same meaning and value as the elements of the same name in the "Audio Specific Config", described in the respective ISO/IEC specification (for example, section 1.6.2.1 of ISO/IEC 14496-3). The parameter "frame Lenght Flag" has the same meaning and value as the elements of the same name in the "GAS pecific Config", described in the respective ISO/IEC specification (eg section 4.4.1, table 4.1 of ISO/IEC 14496 -3).
[0088] The "configuration_word" and the N AAC frames are concatenated to form a message m, which can also be referred to as the second message, which comprises the configuration_word, in addition to the first message, which comprises the concatenation of N AAC frames: m = (configuration_word | AACframe1 | AACframe2 | ... | AACframeN);
[0089] where | denotes concatenation. In the example shown above, the configuration_word is placed in front of the first message. It should be noted that the configuration_word can also be placed in other positions, for example, at the end of the first message.
[0090] In an analogous manner as described above, an HMAC value, eg a HMAC-MD5 code, HMAC(m) by message m is calculated by using the "secret" key K. The key K can be, for example , a certain ASCII code or any other secret value, and the HMAC value of message m is calculated using the HMAC formula mentioned above.
[0091] It should be noted that the cryptographic value of message m can be determined in a sequential manner. This means that, in a first step, the cryptographic value of configuration_word can be determined. This produces a first HMAC value, as a starting state for determining the cryptographic value of AACframe1. The output of this operation is a second HMAC value, which is the starting state for determining the HMAC value of AACframe2, and so on. Eventually, the cryptographic value of AACframeN is determined by using the cryptographic value of AACframeN-1, as a starting state. By using this sequential determination of the HMAC value by message m, that is, by the sequence of frames and/or the configuration_word, it is possible to generate an identifier without increasing the delay incurred by the bit stream. Furthermore, the memory requirements for generating a cryptographic and/or identifier value are kept low, as only the current frame of the bitstream and the starting state, that is, a 128-bit value, needed to be stored. A complete message generation and storage is not necessary.
[0092] To reduce the extra code in the bit stream, caused by the additional identifier, the HMAC value is truncated from 128 bits to a reduced number of bits by eliminating the least significant bits. By way of example, the HMAC value "9e107d9d372bb6826bd3542a419d6" can be truncated to "9e107d9d". The degree of truncation is preferably selected as a compromise between the security of the identifier and the required bit rate overhead. Possible identifier lengths can be, for example, 16, 24, 32, 48, 64, 80, or 96. The truncated HMAC value is the identifier, which is inserted into the identifier_value field of the DSE element.
[0093] Below, other details regarding the encoding process are provided. As already mentioned, it is typically the decoder that decides the number N of AAC frames, which are covered by an identifier. As an example, it may be desirable to ensure that a decoder is able to synchronize with the length of the group of frames in no more than 1 second. Because two identifiers are required for the decoder to synchronize with the length of the group of frames, which is given by the number of frames between two frames comprising an identifier, it must be ensured that the decoder receives at least two identifiers within the range of desired time. Therefore, the encoder must select a value N, so that the time representation of the N AAC frames does not exceed, or exceeds at least, 0.5 second. Since the representation of N AAC frames is dependent on the AAC (core) sample rate, the N value selected by the encoder may vary depending on the AAC (core) sample rate.
[0094] To minimize the bit rate overhead introduced by the identifier, the encoder can select the largest value of N that satisfies the limitation that the time representation of the N AAC frames does not exceed 0.5 second. In some applications, it may be acceptable for the time representation of the N AAC frames to slightly exceed 0.5 second. In these applications, the encoder can select the value of N so that the time representation of the N AAC frames is as close as possible to 0.5 second, although this may in some cases result in the time representation of the N AAC frames slightly exceeding 0.5 second. The extra code, which is introduced by transmitting the identifier, can be determined by evaluating the ratio between the length of the DSE, comprising the identifier, and the overall length of the group of frames (in number of bits).
[0095] Furthermore, it is recommended to align the insertion of an identifier with the insertion of other configuration elements, such as the SBR header. This allows a decoder to easily synchronize to a bit stream and allow reception of all configuration words during a single frame decoding.
[0096] It should be noted that the first AAC frame produced may contain a dummy identifier. The purpose of the first identifier will be to signal to the decoder the start of a sequence of AAC frames comprising identifiers. The decoder will not, however, be in a position to conduct authentication and verification as the identifier would not be based on data from actual means.
[0097] As described in relation to Figure 1, the first calculated identifier covers frames AAC 1 to N and is stored in frame AAC N + 1. The next identifier covers frames AAC N + 1 to 2N and is stored in frame AAC 2N + 1, and so on.
[0098] Figure 2a illustrates a flowchart of the encoding process. In step 201, the encoder is started by providing a number N of frames comprised in a group of frames. Furthermore, key K is provided. In the next step 202, the N frames in a group of frames are concatenated to provide the first message. Then, in step 203, the first message is concatenated with the configuration word to produce the second message. In step 204, the identifier is determined as the truncated version of the HMAC value, calculated by the second message. This identifier is placed in the first frame of the successive frame group (step 205). Finally, the group of frames is transmitted in step 206. It should be noted that the group of transmitted frames contains the identifier of the group of frames transmitted previously. Steps 202 to 206 are repeated until the complete data stream is transmitted.
[0099] As already mentioned, the process mentioned above can be conducted in a sequential iterative manner. This means that the identifier can be determined frame by frame, without the need to first concatenate the N frames and the configuration_word and conduct the HMAC calculation on that complete concatenated message. This is illustrated in Figure 2b. The iterative procedure is started at step 207 by establishing a starting state. The starting state can be the HMAC value of the configuration_word, which is stored in 128-bit memory. Then, an HMAC value can be determined for the first of the N frames (step 208). The resulting HMAC value is stored in 128-bit memory (step 209) and used as a starting state for calculating the HMAC value of the second frame (step 208). This process is repeated until the HMAC value of the Nth frame is determined, where the HMAC value of the (N - 1)th frame is taken from 128-bit memory and used as a start state (step 208). The identifier is determined in the truncated version of the HMAC value from Frame No. (step 210). As an alternative to step 206, each frame can be dispatched immediately after being processed for calculating the HMAC value, without buffering the entire group of frames. The identifier is then added to the (N + 1)th frame and shipped with that frame. This frame is then the first frame to be used in the iterative calculation of the HMAC value for the next N frames. By using this iterative process, the encoding process can be conducted frame by frame at low delay, low computational complexity, and low memory requirements.
[00100] Below, further details are provided regarding the decoding process. Typically, the decoder starts with the consideration that the stream to be decoded does not comprise a valid identifier. That is, an indicator for the presence of a valid identifier in the media bitstream will initially be set to a "false" value, and will only typically be set to a "true" value upon a first successful reception of a valid identifier. This can be indicated on the receiver, for example a frequency signal box, by a visual indicator, such as an LED, which indicates to a user that the received bitstream is an authenticated and valid bitstream. Consequently, the identifier can be used to indicate the quality of a data stream received to a user.
[00101] On the other hand, if the identifier in the decoder is set to "true", but for more than Nmax frames there is no update concerning the identifier within the bit stream, the indicator can be reset to "false". In other words, the decoder may be aware of a maximum value for N, eg Nmax, which must not be exceeded. If the decoder does not detect an identifier valid for more than Nmax frames, then this indicates to the decoder that the received bitstream may not originate from more than one legitimate encoder, or that the received bitstream may have been altered. Consequently, the decoder sets its flag as "false". This will typically result in the visual indicator, eg the LED, being reset.
[00102] The identifier decode procedure is illustrated in Figure 3 and can be described as follows: . the decoder starts and clears the "ID Verified" flag in step 300; . next, the internal memory state (128 bits) is started in step 301; . the decoder waits until a frame is received (step 302) and checks the received frame for the presence of a bitstream identifier in step 303; the presence of an identifier within a frame can be detected via the identifier_sync field specified above; the decoder extracts the identifier_value from the respective field in the <DSE>, in step 307, if an identifier is detected in step 304; . next, the verification identifier is generated by truncating the HMAC value contained in the 128-bit state in step 308; . the decoder continues by comparing the bitstream identifier and the verification identifier in step 309; if it is determined that both IDs are not the same (step 310), the "ID Verified" flag is cleared in step 311 to indicate that the bit stream does not originate from an insecure encoder; in the case of identical IDs, the "ID Verified" flag is set in step 312 to indicate that the bitstream identifier is verified and the bitstream is considered valid because it originates from a secure encoder; in that case, additional aspects of the decoder can be enabled and/or the user informed of the state of checking the bitstream; alternatively, some aspects can be disabled if the bitstream is determined not to originate from a secure encoder and/or, consequently, the informed user; . the decoding process continues at step 313 by initializing the 128-bit internal memory state; . next, the 128-bit HMAC value for the current frame is calculated in step 314 and the 128-bit internal memory state is updated with the HMAC value calculated in step 315; the decoder then returns to step 302 to wait for another frame to be received; . if no identifier is present in the frame (determined in step 304), the decoder proceeds to step 305, in which the decoder determines whether an identifier is present within the last Nmax frames; . in the case where no identifier is present within the last Nmax frames, the decoder clears the "ID Verified" flag in step 306, because the maximum number of Nmax frames passed without an identifier being received; the decoder then returns to step 302 to wait for another frame; and . if an identifier is present within the last Nmax frames, determined in step 305, the decoder proceeds to step 314 to calculate the 128-bit HMAC value for the frame in time.
[00103] As described above, the decoder can determine the verification identifier in a sequential iterative process. This means that only the moment frame is processed and is not required to first concatenate a set of frames, for verification identifier determination. Consequently, identifier decoding can be conducted with low delay, low computational complexity and low memory requirements.
[00104] Figure 4 illustrates an exemplary embodiment of an encoder 400 and a decoder 410 of a data stream. An analog data stream 405, for example an audio stream, is converted to a digital data stream 406 using an analog to digital converter 402. The digital data stream 406 is encoded using an audio encoder 403, for example, Dolby E, Dolby Digital, AAC, HE AAC, DTS, or Dolby Pulse. Audio encoder 403 typically segments the digital data stream 406 into audio frames and provides data compression. What's more, the 403 audio encoder can add metadata. The output of audio encoder 403 is a data stream 407, comprising a plurality of data frames. Thereafter, data stream 407 introduces an additional frame encoder 404, which adds identifiers or cryptographic values to data stream 407. Frame encoder 404 performs in accordance with the aspects described in the present patent document.
[00105] It should be noted that typically the identifiers are determined and added in a sequential manner, so that each frame from the 403 audio encoder is processed directly by the 404 frame encoder. Preferably, the 403 audio encoder and frame encoder 404 form a bundle encoder 401, which can be implemented in a digital signal processor. In this way, aspects of audio encoding and aspects of tag generation can interact. In particular, it may be necessary to consider the additional extra code caused by the identifier when encoding the audio stream. This means that the available bitrate for the audio bitstream can be reduced. This interaction between the audio encoder and tag generation can be used to satisfy a global bandwidth and/or bit rate limitation of certain encoding schemes, eg HE-AAC.
[00106] The bundled encoder 401 transmits a data stream 408, which comprises a plurality of frame groups and associated identifiers. Data stream 408 is typically provided to an associated decoder and/or receiver(s) 410, using various transmission media and/or storage media. It reaches decoder 410 as a data stream 418, which may have changed with respect to data stream 408. Data stream 418 enters a frame decoder 414, which performs verification and authentication of data stream 418, in accordance with the methods and systems described in this patent document. Frame decoder 414 transmits a data stream 417, which typically corresponds to data stream 418, without the identifiers and corresponding data field or syntactic elements. Data stream 417 is decoded in audio decoder 413, where it is decompressed and where added metadata is removed. As described above, frame decoding is typically conducted in a sequential iterative manner, so that processing is conducted frame by frame.
[00107] It should also be noted that the different decoding/receiving components can be grouped together to form a joined decoder. By way of example, frame decoder 414 and audio decoder 413 can form a linked decoder/receiver 411, which can be implemented in a digital signal processor. As described above, this can be beneficial to provide interaction between the audio decoder and the identifier verification. Eventually, the attached decoder/receiver 411 transmits a digital data stream 416, which is converted to an analog audio signal 415, using an analog/digital converter 412.
[00108] It should be noted that in this document, the term "encoder" may refer to the full encoder 400, bonded encoder 401 or frame encoder 404. The term "decoder" may refer to the full decoder 410, bonded decoder 411 or 414 frame decoder. On the other hand, so-called "unsafe encoders" are encoders which do not generate an identifier at all, or which do not generate an identifier according to the methods described in this document.
[00109] Figure 5 illustrates an exemplary broadcast system 500, which comprises a broadcast head-end 504. The head-end 504 also comprises a splice or splicing means, which is operable to combine the bit streams 501, 502 and 503 originating from different coders. Within a broadcast system, these different bitstreams 501, 502 and 503 can be different audio bitstreams, which are typically encoded by different audio encoders. Bitstreams 501, 502 and 503 are composed of a plurality of frames, which are represented by the different shaded blocks. In the illustrative example, bitstream 501 comprises five frames, bitstream 502 comprises four frames, and bitstream 503 comprises six frames. Splicer and/or headend 504 is (are) operable (operable) to combine the bit stream to generate a joined bit stream 505. As shown in the example, this can be done by fixing the bit stream 501 in bitstream 503, and by fixing bitstream 502 in bitstream 501. However, as is also shown in Figure 5, it may only be necessary to select parts of the original bitstreams 501, 502 and 503, for example , only the parts of the audio bitstreams. As such, the combined bitstream 505 comprises only two frames from the bitstream 503, followed by three frames from the bitstream 501, and followed by two frames from the bitstream 502.
[00110] The original bitstreams 501, 502 and 503 can comprise identifiers, that is, the bitstreams 501, 502 and 503 can originate from secure encoders. All identifiers can be based on a different number N of frames. Without loss of generality, the bitstream identifiers 501 and 503 are considered to have been determined for a group of frames comprising two frames. On the other hand, bitstream 502 does not originate from a secure encoder and therefore does not comprise an identifier.
[00111] It is desirable that the splice and/or headend 504 broadcast(s) a bitstream 505, which also comprises an identifier, if the input bitstreams 501 and 503 originate from a secure encoder. This identifier must be sent within the 505 bit stream for all parts of the 505 bit stream that originate from a secure encoder. On the other hand, parts of bit stream 505 which do not originate from a secure encoder, i.e. parts taken from bit stream 502, should not comprise an identifier.
[00112] To achieve this object, the splice and/or headend 504 may be operable (operable) to conduct a decoding and/or encoding of the identifier. As shown in Figure 5, the first two frames of the output bitstream 505 originate from bitstream 503. If these two frames correspond to a group of frames, then the identifier of that group of frames can be placed in the third frame of the bit stream 505. This is described with respect to Fig. 1. If, on the other hand, the two frames belong to different frame groups, then headend 504 may be operable to: . verifying that bitstream 503 originates from a secure encoder; and . generate a new identifier for the output frames of bitstream 503, that is, for the first two frames of bitstream 505.
[00113] The number N used to generate an identifier in the output bitstream 505 does not necessarily have to be the same number N used to generate an identifier in the input bitstreams 501 and 503. This can be seen in the context of the stream. bitstream 501, for which only three frames are included in the output bitstream 505. A first identifier can be generated in the output bitstream 505. A first identifier can be generated for the first two frames, while a second identifier can be generated for the third frame. In other words, N can be two for the first two frames and it cannot be one for the third frame. In general, it can therefore be stated that N can be varied within a 505 bit stream. This is due to the fact that N can be determined independently in the decoder. Preferably, the number N used for the output bitstream 505 is less than or equal to the number N used for the input bitstreams 501 and 503.
[00114] Furthermore, it should be noted that the input bitstream 502 does not comprise an identifier, that is, the bitstream 502 does not originate from a secure encoder. Consequently, the splice and/or headend 504 does not provide an identifier in bitstream 505 for frames originating from bitstream 502. As already described above, the decoder is typically operable to detect the absence of an identifier. in bitstream 505. If the number of frames, which do not comprise an identifier, exceeds a predefined maximum number Nmax, then the decoder will typically detect that a bitstream 505 is no more than a secure encoder.
[00115] As shown by the example of Figure 5, the bit stream 505 can be made up of parts that originate from a secure encoder and other parts, which do not originate from a secure encoder. Consequently, a bit stream 505 may comprise parts that include a valid identifier and other parts that do not include a valid identifier. A 504 splice and/or net head may be operable (operable) to: . detecting input bitstreams comprising an identifier; . forwarding a bitstream, comprising an identifier, as an output bitstream; . authenticate the input bitstream, based on the identifier; and . encode the bitstream with a new identifier.
[00116] In other words, an amender and/or headend 504 may comprise aspects of an encoder and/or a decoder described in the present patent document. That is, a splice and/or headend 504 can function as a decoder when receiving an input bitstream, and can function as an encoder when generating an input bitstream. exit. Furthermore, they may be operable to forward a bit stream, comprising an identifier, without conducting authentication and recoding. This forwarding operation can be conducted for continuous transmission of the same bitstream, while decoding and recoding can preferably be used on the boundaries between bitstreams of different encoders. By using the forward operation, the computational load of the 504 splice and/or headend can be reduced.
[00117] It should be noted that the forward operation can be used in cases where the identifier of a preceding frame group is not influencing the value of the identifier of a currently frame group. In such cases, the frame group and its associated identifier can be seen as an independent entity, which can be routed directly to the output bitstream. On the other hand, if continuous interlinked identifiers are used, when an identifier of a group of frames at the moment depends on the identifier of the previous frame group, then the splice will preferably re-encode the entire bit stream to generate a stream of continuously linked identifiers for the output bitstream. This will ensure that an unauthorized party is not able to replace the segments of the output bitstream.
[00118] It should be noted that, in most cases, the recoding of the amender is only limited to the generation of new identifiers. The bitstream itself, ie, notably, the audio encoding, is typically not affected. Consequently, bitstream recoding can be led to low computational complexity. However, if a cryptographic value is inserted into a frame, which did not previously contain any cryptographic value, then it may be necessary to conduct audio recoding.
[00119] Figure 6 further illustrates the splicing of input bitstreams 1 to 4 into a concatenated output bitstream for a preferred embodiment. In the illustrated example, input bitstream 1 forms groups of 4 frames for the generation of cryptographic values. Angled arrows under the bit stream illustrate that the cryptographic value of one group of frames is inserted into the first frame of the next group. The frames in which the cryptographic values are entered are shaded in the figure. The framegroups of input bitstream 3 comprise 5 frames. Input bitstream 4 does not have any cryptographic values and is unverified and insecure.
[00120] The vertical lines in the figure indicate the splicing points. As can be seen from the figure, the output bitstream comprises a first section I, corresponding to input bitstream 1, a second section II, corresponding to input bitstream 2, a third section III, corresponding to input bitstream 3, and a fourth section IV, corresponding to input bitstream 4, the sections being spliced at the splice points. Up to the first splice point, input bitstream 1, including the cryptographic values, can be copied into the concatenated bitstream. The first cryptographic value in section II, however, needs to be recalculated because, due to the amendment, it refers to different data frames than the corresponding cryptographic value of bitstream 2. In detail, this cryptographic value is generated based on 5 frames, one belonging to input bitstream 1 (before the splice point) and four belonging to input bitstream 2 (after the splice point). Recalculation of cryptographic values is indicated by the arrows above the bit stream and unchanged shading. Because of the spread of variation in the first recalculated cryptographic value in the concatenated bitstream, the following cryptographic values from bitstream 2 also need to be recalculated.
[00121] At the second splice point, the selected bitstream ranges from 2 to 3. The cryptographic value of the first frame of bitstream III is recalculated, based on the previous 6 frames of bitstream 2. At the splice point Next, insecure bitstream 4 is selected and no cryptographic value is inserted in section IV of the concatenated bitstream. Alternatively, a cryptographic value can be generated for the end frames of bitstream 3, copied into the concatenated bitstream, to correctly indicate when the insecure section of the concatenated bitstream ends. This additional cryptographic value is preferably inserted in the first frame of section IV, as indicated in the figure with a dotted circle. Depending on bit rate requirements, it may be necessary to re-encode this frame to make room for entering the additional cryptographic value.
[00122] Figure 7 illustrates another example of concatenating input bitstreams 1 and 2 into an output bitstream. In this case, the splice point is just before a frame carrying a cryptographic value in the second bit stream. The positions of the cryptographic values from the first and second bitstreams must be considered, a large span of cryptographic values will result in the concatenated bitstream. The distance between the cryptographic values in this section of the concatenated bitstream can exceed the maximum value, Nmax, that a decoder accepts without indicating a loss of confidence in the bitstream. Thus, it is preferred to insert an additional cryptographic value at the splice point, for example, in the first frame of the second bit stream, so that the number of frames in the frames does not exceed Nmax. Again, depending on bit rate limitations, it may be necessary to re-encode this frame to make room to insert the additional cryptographic value into the bit stream. As a note, the cryptographic value can in this case be copied from the first frame of bitstream 1, after the splice point, because the additional cryptographic value in the concatenated bitstream refers to the same 6 frames of bitstream 1 The data content of the frame, in which the cryptographic value is included, however, belongs to bitstream 2 (it precisely corresponds to the first frame of bitstream 2, after the splice point).
[00123] This document describes a method and a system, which allow the introduction of an identifier or cryptographic value into a data stream. This identifier can be used to authenticate and verify the data flow. Furthermore, the identifier can be used to ensure that the correct decoder setup is set for the data stream that is to be played back or processed. In particular, the method and system embed additional data, i.e., an identifier, into an HE AAC bitstream, which authenticates that bitstream as originating from a legitimate encoder or transmitter. This can indicate to the receiver that the HE AAC bitstream follows a certain specification and/or a certain quality standard. The identifier is preferably derived from an HDMAC-MD5 calculation.
[00124] The method and system can be used for the authentication of multimedia files and multimedia streams, and can also detect a concatenation of several protected streams, without breaking authentication in general. This means that not a complete stream is checked for consistency, but a set of consecutive frames. This supports typical broadcast scenarios, ie so-called "splicing", where often a device switches between different bitstream encoders to create the effective output stream. Furthermore, the method and system can be used to protect in-band and out-of-band information, where in-band information typically comprises media data and associated metadata, and where out-of-band data typically comprise configuration data. The method and system therefore allow for the control and/or detection of the correct reproduction and/or decoding(s) of a multimedia stream.
[00125] The method and system described in this document can be implemented as software, programming in hardware/or hardware. Certain components can be, for example, implemented as software running on a digital signal processor or microprocessor. Other components can be, for example, implemented as hardware, and/or as application-specific integrated circuits. Signals found in the described method and system can be stored on media such as random access memory or optical storage media. They can be transferred over networks such as radio networks, satellite networks, wireless networks or connected networks, for example the Internet. Typical devices that make use of the method and system described in this document are frequency signal boxes or other customer premises equipment that decode audio signals. On the coding side, the method and system can be used in broadcast stations, for example, in video and audio headend systems.

权利要求:
Claims (13)
[0001]
1. Method for encoding a data stream (100) comprising a plurality of data frames (101,102,103,104,105,106) characterized in that it comprises the steps of: generating (207,208,209,210) a cryptographic value (122) of N successive data frames (112 ) and configuration information using a cryptographic hash function, with N>1; wherein the configuration information comprises information for synthesizing the data stream (100); wherein generating (207,208,209,210) the cryptographic value (122) of the N successive data frames (112) comprises iteratively generating (208) an intermediate cryptographic value of each of the N successive data frames (112) using a start state of the value intermediate cryptographic until an intermediate cryptographic value of the nth data frame (105) is generated, the intermediate cryptographic value of the nth data frame (105) representing the cryptographic value (122) of the successive N data frames (112); wherein the starting state of the first data frame (103) of the N successive data frames (112) is an intermediate cryptographic value of the configuration information, wherein the starting state of each subsequent data frame (104,105) of the N successive data frames (112) is the intermediate cryptographic value of the data frame (103,104) of the N successive data frames (112), which precedes the subsequent data frame (104,105) of the N successive data frames (112); and inserting (205) the cryptographic value (122) of the successive N data frames (112) into a frame (106) of the subsequent data stream (100) to the successive N data frames (112).
[0002]
2. Method according to claim 1, characterized in that the cryptographic value (122) is inserted as a data stream element (DSE); and wherein the data stream element (DSE) is a syntactic element of the data frame (106) of the data stream (100) and wherein the data stream (100) is an MPEG4-AAC or MPEG2-AAC stream .
[0003]
3. Method according to claim 1 or 2, characterized in that the configuration information comprises at least one of: an indication of a sampling rate; an indication of a channel configuration of an audio coding system; an indication of the number of samples in a data frame (101,102,103,104,105,106).
[0004]
4. Method according to any one of claims 1 to 3, characterized in that it comprises selecting N so that the N successive data frames (112) cover as close as possible to a predetermined duration of a corresponding signal when reproduced with an appropriate setting.
[0005]
5. Method for verifying a data stream (100) in a decoder (414), the data stream (100) comprising a plurality of data frames (101,102,103,104,105,106) and a cryptographic value (122) associated with N successive data frames (112) above, with N>1, characterized in that it comprises the steps of: generating (308) a second cryptographic value of the N successive data frames (112) and configuration information using a cryptographic hash function; wherein the configuration information comprises information for synthesizing the data stream (100); wherein generating the second cryptographic value of the N successive data frames (112) comprises iteratively generating (208) a second intermediate cryptographic value of each of the N successive data frames (112) using a start state of the intermediate cryptographic value until a second intermediate cryptographic value of the nth data frame (105) is generated, the second intermediate cryptographic value of the nth data frame (105) representing the second cryptographic value of the N successive data frames (112); wherein the starting state of the first data frame (103) of the N successive data frames (112) is an intermediate second cryptographic value of the configuration information, wherein the starting state of each subsequent data frame (104,105) of the N successive data frames (112) is the second intermediate cryptographic value of the data frame (103,104) of the N successive data frames (112), which precedes the subsequent data frame (104,105) of the N successive data frames (112) ; extracting (307) the cryptographic value (122) from a data frame (106) of the data stream (100); and comparing (309) the cryptographic value (122) with the second cryptographic value.
[0006]
6. Method according to claim 5, characterized in that the data stream (100) is a stream MPEG4-AAC or MPEG2-AAC; wherein the cryptographic value (122) is extracted from a data stream element (DSE); and wherein the data stream element (DSE) is a syntactic element of the data frame (106) of the data stream (100).
[0007]
7. Method according to claim 5 or 6, characterized in that the cryptographic value (112), which is generated by calculating a HMAC-MD5 value (hash message authentication code), is a truncated version of a longer cryptographic value, and wherein generating (308) the second cryptographic value comprises truncating the second cryptographic value.
[0008]
8. Method according to claim 7, characterized in that a length of the cryptographic value is 16, 24, 32, 48, 64, 80, 96 or 112 bits, and in that the second cryptographic value is truncated to the length of the cryptographic value.
[0009]
9. Data stream (100) characterized in that it comprises a cryptographic value (122) generated and entered according to the method as defined in any one of claims 1 to 4.
[0010]
10. Encoder (404) operable to encode a data stream (100) comprising a plurality of data frames (101,102,103,104,105,106) characterized in that it comprises a processor operable to: generate a cryptographic value (122) of N data frames successive (112) and configuration information using a cryptographic hash function, with N>1; wherein the configuration information comprises information for synthesizing the data stream (11); wherein generating the cryptographic value (122) of the N successive data frames (112) comprises iteratively generating an intermediate cryptographic value of each of the N successive data frames (112) using a starting state of the intermediate cryptographic value to a cryptographic value intermediate of the nth data frame (105) is generated, the intermediate cryptographic value of the nth data frame (105) representing the cryptographic value (122) of the successive N data frames (112); wherein the starting state of the first data frame (103) of the N successive data frames (112) is an intermediate cryptographic value of the configuration information, wherein the starting state of each subsequent data frame (104,105) of the N successive data frames (112) is the intermediate cryptographic value of the data frame (103,104) of the N successive data frames (112), which precedes the subsequent data frame (104,105) of the N successive data frames (112); and inserting the cryptographic value (122) into a frame (106) of the data stream (100) subsequent to the N successive data frames (112).
[0011]
11. Decoder (414) operable to verify a data stream (100) comprising a plurality of data frames (101,102,103,104,105,106) and a cryptographic value (122) associated with N successive data frames (112) preceding, with N>1 characterized in that it comprises a processor operable to: generate a second cryptographic value of N successive frames of data (112) and configuration information using a cryptographic hash function; wherein the configuration information comprises information for synthesizing the data stream (100); wherein generating the second cryptographic value of the N successive data frames (112) comprises iteratively generating a second intermediate cryptographic value of each of the N successive data frames (112) using a start state of the intermediate cryptographic value to a second cryptographic value intermediate of the nth data frame (105) is generated, the second intermediate cryptographic value of the nth data frame (105) representing the second cryptographic value of the successive N data frames (112); wherein the starting state of the first data frame (103) of the N successive data frames (112) is an intermediate second cryptographic value of the configuration information, wherein the starting state of each subsequent data frame (104,105) of the The successive N data frames (112) is the second intermediate cryptographic value of the data frame (103,104) of the N successive data frames (112), which precedes the subsequent data frame (104,105) of the N successive data frames (112) ; extracting the cryptographic value (122) from a data frame (106) of the data stream (100); and comparing the cryptographic value (122) with the second cryptographic value.
[0012]
12. Storage medium characterized in that it comprises a computer program adapted to run on a processor and to perform the steps of the method as defined in any one of claims 1 to 8 when run on a computing device.
[0013]
13. Method for concatenating first and second bitstreams (501,502), each comprising a plurality of data frames (101,102,103,104,105,106) and a cryptographic value (122) associated with a certain number of data frames (101,102,103,104,105,106) characterized in that it comprises the step of generating a concatenated bitstream (505) from the first and second bitstreams (501,502), wherein the concatenated bitstream (505) comprises at least a part of the plurality of frames of data (101,102,103,104,105,106) from the first and second bitstreams (501,502), and comprises a cryptographic value (122) generated and entered according to the method as defined in any one of claims 1 to 4.

类似技术:

---

公开号 | 公开日 | 专利标题

---

BR112012002831B1|2021-08-31|Method for encoding a data stream, method for verifying a data stream, data stream, encoder, decoder, storage medium, and method for concatenating a first and a second bit stream

---

US10554415B2|2020-02-04|Metadata transcoding

---

ES2739886T3|2020-02-04|Data processor and transport of user control data to audio decoders and renderers

---

KR101673131B1|2016-11-07|Audio encoder and decoder with program information or substream structure metadata

---

EP2647006B1|2019-09-18|Adaptive processing with multiple media processing nodes

---

BRPI0908035B1|2020-11-24|METHOD TO PRODUCE A COMPUTER FILE FOR INCLUSION IN AN AUDIO PACKAGE, MOVEMENT ENCODER, METHOD FOR DECODING, IN REAL TIME, A MULTI-CHANNEL VIBRO-CINETIC SIGN, AND MOVEMENT DECODER

---

BRPI0620700A2|2011-12-06|method for encoding and decoding conditional access content

---

KR0177314B1|1999-05-01|Apparatus for protecting transport packet in mpeg system

---

CN111064717A|2020-04-24|Data encoding method, data decoding method, related terminal and device

---

AU2020200861A1|2020-02-27|Adaptive Processing with Multiple Media Processing Nodes

---

BR122020007952B1|2021-10-13|AUDIO DECODING METHOD AND AUDIO DECODING DEVICE

---

BR122020007965B1|2021-10-13|AUDIO DECODING METHOD AND AUDIO DECODING SYSTEM

同族专利:

---

公开号 | 公开日

---

EP2462587B1|2016-07-06|

---

AR077680A1|2011-09-14|

---

TWI501580B|2015-09-21|

---

IL217469A|2015-02-26|

---

HK1168461A1|2012-12-28|

---

US8885818B2|2014-11-11|

---

CN102576559A|2012-07-11|

---

AU2010280971B2|2013-02-14|

---

CA2768327A1|2011-02-10|

---

SG177605A1|2012-02-28|

---

WO2011015369A8|2012-03-01|

---

KR20120050446A|2012-05-18|

---

WO2011015369A1|2011-02-10|

---

MX2012001558A|2012-04-10|

---

RU2509424C2|2014-03-10|

---

UA104483C2|2014-02-10|

---

AU2010280971A1|2012-02-09|

---

CN102576559B|2015-09-09|

---

JP2013500655A|2013-01-07|

---

EP2462587A1|2012-06-13|

---

CA2768327C|2015-10-27|

---

JP5542205B2|2014-07-09|

---

BR112012002831A2|2021-01-26|

---

KR101489364B1|2015-02-03|

---

TW201134135A|2011-10-01|

---

MY152679A|2014-10-31|

---

IL217469D0|2012-03-01|

---

US20120128151A1|2012-05-24|

---

RU2012107995A|2013-09-20|

引用文献:

---

公开号 | 申请日 | 公开日 | 申请人 | 专利标题

---

---

US5463424A|1993-08-03|1995-10-31|Dolby Laboratories Licensing Corporation|Multi-channel transmitter/receiver system providing matrix-decoding compatible signals|

---

EP0959620B1|1993-11-18|2005-01-12|Digimarc Corporation|Video with hidden in-band digital data|

---

US5646997A|1994-12-14|1997-07-08|Barton; James M.|Method and apparatus for embedding authentication information within digital data|

---

US5915027A|1996-11-05|1999-06-22|Nec Research Institute|Digital watermarking|

---

US6009176A|1997-02-13|1999-12-28|International Business Machines Corporation|How to sign digital streams|

---

US7197156B1|1998-09-25|2007-03-27|Digimarc Corporation|Method and apparatus for embedding auxiliary information within original data|

---

KR100746018B1|1999-03-10|2007-08-06|디지맥 코포레이션|Signal processing methods, devices, and applications for digital rights management|

---

US6904089B1|1998-12-28|2005-06-07|Matsushita Electric Industrial Co., Ltd.|Encoding device and decoding device|

---

US6785815B1|1999-06-08|2004-08-31|Intertrust Technologies Corp.|Methods and systems for encoding and protecting data using digital signature and watermarking techniques|

---

GB9929364D0|1999-12-10|2000-02-02|Microbar Security Limited|Improvements in or relating to coding techniques|

---

US7058815B2|2001-01-22|2006-06-06|Cisco Technology, Inc.|Method and system for digitally signing MPEG streams|

---

US6996717B2|2001-05-24|2006-02-07|Matsushita Electric Industrial Co., Ltd.|Semi-fragile watermarking system for MPEG video authentication|

---

WO2003024020A1|2001-09-10|2003-03-20|Entriq Limited Bvi|Method and computer system to perform on the fly fingerprinting for media content|

---

RU2308077C2|2001-12-04|2007-10-10|Майкрософт Корпорейшн|Methods and systems for cryptographic protection of protected content|

---

GB2392337B|2002-07-19|2005-12-07|Matsushita Electric Ind Co Ltd|Digital watermarking apparatus and application apparatus using the same|

---

US7360093B2|2002-07-22|2008-04-15|Xerox Corporation|System and method for authentication of JPEG image data|

---

US20040243820A1|2003-05-14|2004-12-02|Kenichi Noridomi|Information-embedding apparatus and method, tampering-detecting apparatus and method, and recording medium|

---

JP2004364263A|2003-05-14|2004-12-24|Matsushita Electric Ind Co Ltd|Information embedding apparatus and method, tampering detecting apparatus and method, and recording medium|

---

GB0317571D0|2003-07-26|2003-08-27|Koninkl Philips Electronics Nv|Content identification for broadcast media|

---

US7417989B1|2003-07-29|2008-08-26|Sprint Spectrum L.P.|Method and system for actually identifying a media source in a real-time-protocol stream|

---

WO2005017809A2|2003-08-15|2005-02-24|Docomo Communications Laboratories Usa, Inc.|Method and apparatus for authentication of data streams with adaptively controlled losses|

---

GB0403331D0|2004-02-14|2004-03-17|Koninkl Philips Electronics Nv|Watermark detection|

---

US8539608B1|2004-03-25|2013-09-17|Verizon Corporate Services Group Inc.|Integrity checking at high data rates|

---

JP2005318068A|2004-04-27|2005-11-10|Kddi Corp|Electronic watermark embedding system of contents authentication data, and authentication system|

---

JP4499631B2|2005-08-31|2010-07-07|株式会社日立国際電気|Image receiving apparatus and program|

---

US7752449B1|2006-02-22|2010-07-06|Avaya, Inc.|System and method for generating a non-repudiatable record of a data stream|

---

KR100781528B1|2006-06-29|2007-12-03|삼성전자주식회사|Device and method for providing video stream with integrity|

---

US20080005558A1|2006-06-29|2008-01-03|Battelle Memorial Institute|Methods and apparatuses for authentication and validation of computer-processable communications|

---

US20080010466A1|2006-07-10|2008-01-10|William Hopper|Digital identifier chaining|

---

US8655652B2|2006-10-20|2014-02-18|Dolby International Ab|Apparatus and method for encoding an information signal|

---

WO2009046438A1|2007-10-05|2009-04-09|Dolby Laboratories Licensing Corp.|Media fingerprints that reliably correspond to media content|

---

US7930554B2|2007-05-31|2011-04-19|Vasco Data Security,Inc.|Remote authentication and transaction signatures|

---

JP5101964B2|2007-09-25|2012-12-19|京セラ株式会社|Receiver|

---

JP2009093506A|2007-10-11|2009-04-30|Sony Corp|Signal processing apparatus, signal processing method and signal processing program|

---

JP4584300B2|2007-12-19|2010-11-17|富士通株式会社|Electronic signature program, computer-readable recording medium, electronic signature device, and electronic signature method|

---

US8798776B2|2008-09-30|2014-08-05|Dolby International Ab|Transcoding of audio metadata|

---

EP3217395A1|2008-10-29|2017-09-13|Dolby International AB|Signal clipping protection using pre-existing audio gain metadata|

---

TWI538394B|2009-04-10|2016-06-11|杜比實驗室特許公司|Obtaining a desired non-zero phase shift using forward-backward filtering|

---

CN102667920B|2009-12-16|2014-03-12|杜比国际公司|SBR bitstream parameter downmix|

---

TWI447709B|2010-02-11|2014-08-01|Dolby Lab Licensing Corp|System and method for non-destructively normalizing loudness of audio signals within portable devices|

---

TWI525987B|2010-03-10|2016-03-11|杜比實驗室特許公司|System for combining loudness measurements in a single playback mode|TWI538394B|2009-04-10|2016-06-11|杜比實驗室特許公司|Obtaining a desired non-zero phase shift using forward-backward filtering|

---

TWI413110B|2009-10-06|2013-10-21|Dolby Int Ab|Efficient multichannel signal processing by selective channel decoding|

---

EP2491560B1|2009-10-19|2016-12-21|Dolby International AB|Metadata time marking information for indicating a section of an audio object|

---

US9210456B1|2012-03-07|2015-12-08|The Directv Group, Inc.|Method and system for detecting unauthorized use of a user device using receiver identification in a network|

---

US9813705B2|2012-04-26|2017-11-07|Qualcomm Incorporated|Parameter set coding|

---

JPWO2014050597A1|2012-09-28|2016-08-22|シャープ株式会社|Image decoding device|

---

ES2629195T3|2013-01-21|2017-08-07|Dolby Laboratories Licensing Corporation|Encoding and decoding of a bit sequence according to a confidence level|

---

KR101428770B1|2013-05-29|2014-08-08|한국전자통신연구원|Apparatus and method for performing compression operation in hash algorithm|

---

KR101516573B1|2013-07-26|2015-05-04|한국전자통신연구원|Apparatus and method for performing compression operation in hash algorithm|

---

WO2015024603A1|2013-08-23|2015-02-26|Nec Europe Ltd.|Method and system for authenticating a data stream|

---

FR3015167A1|2013-12-13|2015-06-19|Orange|MULTIPOINT MULTIPOINT RADIO DATA TRANSPORT SYSTEM|

---

CN106471831B|2014-09-30|2019-11-29|华为技术有限公司|The method of configuration, the device of configuration and equipment|

---

JP2016122917A|2014-12-24|2016-07-07|パナソニックＩｐマネジメント株式会社|Signature generation device, signature verification device, signature generation method and signature verification method|

---

BR112017022000A2|2015-04-13|2018-07-03|Bayer Cropscience Ag|n-cycloalkyl-n--carboxamide derivatives.|

---

US10304467B2|2015-04-24|2019-05-28|Sony Corporation|Transmission device, transmission method, reception device, and reception method|

---

CN107637159B|2015-05-19|2021-04-20|瑞典爱立信有限公司|Method for managing contention resolution, wireless communication device and radio network node|

---

JP2017009663A|2015-06-17|2017-01-12|ソニー株式会社|Recorder, recording system and recording method|

---

CN106610995B|2015-10-23|2020-07-07|华为技术有限公司|Method, device and system for creating ciphertext index|

---

TWI589153B|2015-12-29|2017-06-21|晨星半導體股份有限公司|Method for Detecting Data Stream Synchronization|

---

CN107040793A|2016-02-04|2017-08-11|晨星半导体股份有限公司|The synchronization detecting method of data flow|

---

DE102016207642A1|2016-05-03|2017-11-09|Siemens Aktiengesellschaft|Method and apparatus for authenticating a data stream|

---

US9870508B1|2017-06-01|2018-01-16|Unveiled Labs, Inc.|Securely authenticating a recording file from initial collection through post-production and distribution|

---

KR102275868B1|2017-11-07|2021-07-12|한국전자기술연구원|Apparatus and Method for Falsification Protection of Video Data|

---

US10956246B1|2018-07-16|2021-03-23|Amazon Technologies, Inc.|Isolated read channel management interfaces at streaming data service|

法律状态:
2021-02-02| B06U| Preliminary requirement: requests with searches performed by other patent offices: procedure suspended [chapter 6.21 patent gazette]|

---

2021-05-11| B06A| Patent application procedure suspended [chapter 6.1 patent gazette]|

---

2021-07-13| B09A| Decision: intention to grant [chapter 9.1 patent gazette]|

---

2021-08-31| B16A| Patent or certificate of addition of invention granted [chapter 16.1 patent gazette]|Free format text: PRAZO DE VALIDADE: 20 (VINTE) ANOS CONTADOS A PARTIR DE 06/08/2010, OBSERVADAS AS CONDICOES LEGAIS. PATENTE CONCEDIDA CONFORME ADI 5.529/DF, QUE DETERMINA A ALTERACAO DO PRAZO DE CONCESSAO. |

优先权:

---

申请号 | 申请日 | 专利标题

---

US23229509P| true| 2009-08-07|2009-08-07|

---

US61/232,295|2009-08-07|

---

PCT/EP2010/004827|WO2011015369A1|2009-08-07|2010-08-06|Authentication of data streams|

---