Data stream authentication
Abstract
FIELD: radio engineering, communication. SUBSTANCE: disclosed is a method and a system for decoding a data stream which includes a series of data frames, where the method includes a step of generating a cryptographic value for a block of N consecutive data frames and configuration information, characterised by that the configuration information includes information for rendering the data stream; the method then inserts the cryptographic value into the data stream, following the N consecutive data frames. EFFECT: enabling to make a distinction between a data stream, or a bit stream, or a bit stream generated by a corresponding Dolby Pulse encoder and a data stream, or a bit stream, generated by any arbitrary encoder compatible with HE-AACv2. 38 cl, 8 dwg

Term
3.9 yearsleft in the term
Expires 6 August 2030.
- Priority
- Filed
- Granted
- Today
- Expires
38 claims: 35 independent, 3 dependent
- 1Способ кодирования потока данных, включающего ряд кадров данных, где способ включает этапы, на которых br / - генерируют криптографическую величину для блока из N последовательных кадров данных из ряда кадров данных и информации о конфигурации с использованием криптографической хэш-функции;где информация о конфигурации включает информацию для рендеринга потока данных;и br / - осуществляют вставку криптографической величины в кадр потока данных, следующий за N последовательными кадрами данных;и br / - осуществляют генерирование промежуточной криптографической величины для каждого из N последовательных кадров блока с использованием исходного состояния;где исходное состояние представляет собой промежуточную криптографическую величину предыдущего кадра блока;и где исходное состояние первого кадра блока представляет собой промежуточную криптографическую величину для информации о конфигурации, и где криптографическая величина представляет собой промежуточную криптографическую величину N-го кадра блока.
- 2Способ по п. 1, отличающийся тем, что криптографическую величину вставляют в элемент DSE потока данных;где элемент DSE потока данных представляет собой синтаксический элемент кадра потока данных;и где поток данных представляет собой поток MPEG4-AAC или MPEG2-AAC.
- 3Способ по п. 1, отличающийся тем, что количество кадров N больше единицы.
- 4Способ по п. 1, отличающийся тем, что кадры данных представляют собой видео- или аудиокадры.
- 5Способ по п. 1, отличающийся тем, что кадры данных представляют собой кадры AAC или HE-AAC.
- 6Способ по п. 1, отличающийся тем, что информация о конфигурации включает, по меньшей мере, один из следующих указателей:br / - указатель частоты дискретизации;br / - указатель конфигурации каналов системы кодирования звукового сигнала;br / - указатель количества дискретных значений в кадре данных.
- 7Способ по п. 1, отличающийся тем, что криптографическую величину генерируют с использованием ключевой величины.
- 8Способ по п. 7, отличающийся тем, что этап генерирования криптографической величины включает br / - вычисление значения HMAC-MD5 для блока из N последовательных кадров данных и информации о конфигурации.
- 9Способ по п. 8, отличающийся тем, что этап генерирования криптографической величины включает br / - усечение значения HMAC-MD5 для получения криптографической величины.
- 10Способ по п. 9, отличающийся тем, что значение HMAC-MD5 усекается до 16, 24, 32, 48, 64, 80, 96 или 112 бит.
- 11Способ по п.1, отличающийся тем, что криптографическую величину для блока из N последовательных кадров данных вставляют в следующий кадр данных потока данных, следующий за блоком из N последовательных кадров данных.
- 12Способ по п. 1, отличающийся тем, что дополнительно включает этап, на котором br / - вставляют указатель синхронизации после блока из N последовательных кадров данных, где указатель синхронизации указывает на то, что криптографическая величина была вставлена.
- 13Способ по п. 1, отличающийся тем, что элемент DSE потока данных вставляют в конец кадра перед элементом TERM .
- 14Способ по п. 1, отличающийся тем, что содержимое элемента DSE потока данных выровнено по границе байта потока данных.
- 15Способ по п. 1, отличающийся тем, что этапы генерирования и вставки криптографической величины повторяют для ряда блоков из N последовательных кадров данных.
- 16Способ по п. 1, отличающийся тем, что включает этап, на котором br / - выбирают N таким образом, чтобы блок из N последовательных кадров максимально возможно близко покрывал заранее определенную длительность соответствующего сигнала при воспроизведении в соответствующей конфигурации.
- 17Способ по п. 16, отличающийся тем, что включает этап, на котором br / - выбирают N таким образом, чтобы заранее определенная длительность не была превышена.
- 18Способ по одному из пп.16 или 17, отличающийся тем, что заранее определенная длительность составляет 0,5 секунд.
- 19Способ по п.4, отличающийся тем, что дополнительно включает этап, на котором br / - осуществляют взаимодействие с видео- и/или аудиокодером потока данных.
- 20Способ по п. 19,отличающийся тем, что на этапе взаимодействия с видео- и/или аудиокодером потока данных осуществляют br / - установку для видео- и/или аудиокодера такой максимальной битовой скорости передачи данных, чтобы указанная битовая скорость передачи данных для потока данных, включающего криптографическую величину, не превышала заранее определенное значение.
- 21Способ декодирования для верификации потока данных в декодере, где поток данных включает ряд кадров данных и криптографическую величину, связанную с блоком из N последовательных кадров данных, где способ включает этапы, на которых br / - генерируют вторую криптографическую величину для блока из N последовательных кадров данных и информации о конфигурации с использованием криптографической хэш-функции;где информация о конфигурации включает информацию для рендеринга данных;где генерирование второй криптографической величины включает генерирование промежуточной криптографической величины для каждого из N последовательных кадров с использованием исходного состояния;где исходное состояние представляет собой промежуточную вторую криптографическую величину предыдущего кадра блока;где исходное состояние первого кадра блока представляет собой промежуточную вторую криптографическую величину для информации о конфигурации;где вторая криптографическая величина представляет собой промежуточную криптографическую величину N-го кадра блока;br / - извлекают криптографическую величину из потока данных;и br / - сравнивают криптографическую величину со второй криптографической величиной для верификации потока данных.
- 22Способ по п. 21, отличающийся тем, что поток данных представляет собой поток MPEG4-AAC или MPEG2-AAC;где криптографическая величина извлекается из элемента DSE потока данных;и где элемент DSE потока данных представляет собой синтаксический элемент кадра потока данных.
- 23Способ по п. 21, отличающийся тем, что поток данных включает ряд блоков из N последовательных кадров данных и связанных с ними криптографических величин, и где способ дополнительно включает этап, на котором br / - определяют число N как количества кадров между двумя последовательными криптографическими величинами.
- 24Способ по п. 21, отличающийся тем, что криптографическую величину генерируют в соответствующем кодере из N последовательных кадров данных и информации о конфигурации согласно способу, который соответствует способу, используемому для генерирования второй криптографической величины.
- 25Способ по п. 24, отличающийся тем, что br / - криптографическую величину и вторую криптографическую величину генерируют с использованием уникального ключевого значения и уникальной криптографической хэш-функции.
- 26Способ по одному из п.п. 21-25, отличающийся тем, что дополнительно включает этапы, на которых br / - устанавливают флаг в случае, когда криптографическая величина соответствует второй криптографической величине;и br / - обеспечивают визуальную индикацию, если флаг установлен.
- 27Способ по п. 21, отличающийся тем, что дополнительно включает этап, на котором br / - осуществляют сброс флага, если криптографическая величина не соответствует второй криптографической величине или если криптографическая величина не может быть извлечена из потока данных.
- 28Кодер для кодирования потока данных, включающего ряд кадров данных, где кодер содержит процессор, действующий для:br / - генерирования криптографической величины для блока из N последовательных кадров данных из ряда кадров данных и информации о конфигурации с использованием криптографической хэш-функции;где информация о конфигурации включает информацию для рендеринга потока данных;br / - вставки криптографической величины в кадр потока данных, следующий за N последовательными кадрами данных;и br / - генерирования промежуточной криптографической величины для каждого из N последовательных кадров блока с использованием исходного состояния;где исходное состояние представляет собой промежуточную криптографическую величину предыдущего кадра блока;и где исходное состояние первого кадра блока представляет собой промежуточную криптографическую величину для информации о конфигурации, и где криптографическая величина представляет собой промежуточную криптографическую величину N-го кадра блока.
- 29Декодер для верификации потока данных, включающего ряд кадров данных и криптографическую величину, связанную с блоком из N последовательных кадров данных, где декодер содержит процессор, действующий для:br / - генерирования второй криптографической величины для блока из N последовательных кадров данных и информации о конфигурации с использованием криптографической хэш-функции;где информация о конфигурации включает информацию для рендеринга данных;где генерирование второй криптографической величины включает генерирование промежуточной криптографической величины для каждого из N последовательных кадров с использованием исходного состояния;где исходное состояние представляет собой промежуточную вторую криптографическую величину предыдущего кадра блока;где исходное состояние первого кадра блока представляет собой промежуточную вторую криптографическую величину для информации о конфигурации;где вторая криптографическая величина представляет собой промежуточную криптографическую величину N-го кадра блока;br / - извлечения криптографической величины из кадра потока данных;и br / - сравнения криптографической величины со второй криптографической величиной для верификации потока данных.
- 30Носитель данных, который включает программу, реализованную программно, адаптированную для исполнения на процессоре и для выполнения этапов способа по одному из пп. 1-20 при осуществлении на вычислительном устройстве.
- 31Носитель данных, который включает программу, реализованную программно, адаптированную для исполнения на процессоре и для выполнения этапов способа по одному из пп. 21-27 при осуществлении на вычислительном устройстве.
- 32Внешнее дополнительное устройство, предназначенное для декодирования принятого потока данных, включающего звуковой сигнал, где внешнее дополнительное устройство включает декодер по п. 29, предназначенный для верификации принятого потока данных.
- 33Переносное электронное устройство, предназначенное для декодирования принятого потока данных, включающего звуковой сигнал, где переносное электронное устройство включает декодер по п. 29, предназначенный для верификации принятого потока данных.
- 34Компьютер, предназначенный для декодирования принятого потока данных, включающего звуковой сигнал;где компьютер включает декодер по п. 29, предназначенный для верификации принятого потока данных.
- 35Система вещания, предназначенная для передачи потока данных, включающего звуковой сигнал;где система вещания включает кодер по п. 28.
- 36Способ конкатенации первого и второго битовых потоков, каждый из которых включает ряд кадров данных и криптографическую величину, связанную с заданным количеством кадров данных, где способ включает этап, на котором br / - генерируют конкатенированный битовый поток из первого и второго битовых потоков, где конкатенированный битовый поток включает, по меньшей мере, часть ряда кадров данных из первого и второго битовых потоков и включает криптографическую величину, генерируемую и вставляемую в соответствии со способом по одному из пп. 1-20.
- 37Устройство для конкатенации, действующее для конкатенации первого и второго битовых потоков, каждый из которых включает ряд кадров данных и криптографические величины, связанные с заданным количеством кадров данных, где устройство для конкатенации содержит br / - кодер по п. 28, предназначенный для кодирования последних кадров первого битового потока и первых кадров второго битового потока.
- 38Устройство для конкатенации по п. 37, отличающееся тем, что дополнительно содержит:br / - декодер по п. 29, предназначенный для верификации последних кадров первого битового потока, первых кадров второго битового потока и связанных с ними криптографических величин;и br / блок управления, который разблокирует кодер для вставки криптографических величин в конкатенированный битовый поток только в том случае, если соответствующий первый и второй битовые потоки аутентифицированы.
Independent claims38
150 paragraphs in 4 sections, as filed
TECHNICAL FIELD
The present invention relates to methods of authentication and verification of the data streams. In particular, the invention relates to the insertion of the identifiers in the data stream such as Dolby Pulse bitstream, AAC or HE AAC, and to the authentication and verification of the data stream on the basis of this identifier.
BACKGROUND OF THE INVENTION
In the context of the growing spread of digital television and radio data streams, including, for example, video and / or audio broadcast more often. In addition to the actual video and / or audio content, these data streams also include metadata that can, for example, to control the volume and dynamic range of the program at the receiver, and control the stereo downmix and other properties.
In a typical network scenario video frames and / or audio frames and associated metadata encoded in the broadcast network the headend. This may use different coding schemes, such as Dolby E, Dolby Digital, AAC, HE AAC, DTS or Dolby Pulse. Some of these coding schemes, Dolby Pulse, AAC and HE AAC, to the greatest extent, and are particularly well suited for transmission through the various means of information transmission, such as radio (e.g., FM-frequency range, DVB / T, ATSC), stranded copper wires (DSL), coaxial cables (e.g., CATV) or optical fibers. A receiver such as a TV, radio, personal computer or external device further comprises a corresponding decoder, and creates a decoded media stream. In addition, the receiver typically includes control functions which are initiated by the metadata accompanying the video and / or audio.
Examples of arrangements of the encoding / decoding defined in the standard ISO / IEC 14496-3 (2005) "Information technology - Coding of audio-visual objects - Part 3: Audio" - MPEG-4 AAC, and in standard ISO / IEC 13818-7 ( 2003) "Generic Coding of Moving Pictures and Associated Audio information - Part 7: Advanced Audio Coding (AAC)" - for MPEG-2 AAC, which reference is incorporated herein.
Several methods for authentication and / or identification. Some of these rely on the introduction of authentication data and / or identification in the encoded media data. These methods are known as "watermarks" and intended mainly to protect the copyright. Another method for authentication and / or identification - a digital signature which provides some authentication data along with data files, such as e-mail files, and the decoder used for authentication and identification.
In order for the data stream receiver I was able to identify the encoder data stream is required along with the data stream to provide a means of authentication. It may also be useful in checking the integrity of the data stream. Furthermore, it may be useful to ensure a correct configuration of the receiver in respect of the data stream, which is subjected to reproduction or processing. It may also be useful to implement admission added services or special features to the data streams that have been properly authenticated and / or verified. To these and other questions, please contact the real patent document.
SHORT DESCRIPTION
The proposed method and system use an identifier that may be provided as metadata in the data stream. These streams of data preferably represent data streams which are transmitted via wired or wireless transmission media, however, the data streams may also be provided on a storage device such as a CD, DVD, or flash memory. The identifier allows the decoder on the receiving side to check whether the data stream that it receives, originating from a reliable encoder, ie from legitimate encoder on the transmission side and / or coding. This verification can be particularly useful in the case where the decoder is compatible with different types of encoders. For example, Dolby Pulse decoder can be compatible with the encoder HE-AAC version 2. In this scenario, it may be necessary to provide a decoder Dolby Pulse ability to provide some non-standard or optional, is only possible if the network traffic, ie data streams derived from the respective encoders Dolby Pulse. When using said identifier Pulse Dolby decoder will have the ability to distinguish between the data stream or bit stream, which is generated by the respective Dolby Pulse encoder, and the data stream or bit stream, which is generated by any arbitrary encoder compatible with HE-AACv2. In this regard, it can be ensured that the additional features such as the use of dynamic metadata recorded in the decoder only if the data stream coming from a reliable encoder. Thus, there can be provided the correct functioning of additional features.
An additional advantage of the identifier is that it can provide the decoder to verify that the bit stream has been received correctly, and that the bit stream is not subjected to tampering or modification during transmission. In other words, the identifier enables the decoder to verify the integrity of the received bitstream.
Also, the identifier can be used to ensure that the decoder is set to the correct configuration processing, such as reproduction, in order to properly render the media / multimedia signal. For example, the configuration can be directed to the sample rate, which is reproduced mediasignal. Configuration may also be directed to configuring channels, such as 2-channel stereo signal, the surround other settings, etc., to be used during playback. Another feature of the configuration can be sent to a frame length, for example 1024 frames of discrete values, or discrete values of the frame 960 in the case of the AAC, which is used in a particular encoding scheme.
Apart from the purposes of identification and authentication of the encoder, the identifier can be used to verify the authenticity of the payload data stream. For this purpose, the identifier should not be easily subject to forgery and manipulation of a protected segment must be identifiable. Furthermore, it is desirable that the decoder determines the authenticity of a bit stream in a relatively short time intervals. Preferably, the maximum time for which the decoder or decoding apparatus is able to identify authentic bit stream in streaming mode does not exceed 1 second. Moreover, the complexity introduced by the verification identifier to the decoder to be maintained at a low level, i.e. an increase in the complexity of the decoder should be negligible. Finally, it should be kept low overhead when transmitting introduced identifier.
According to one embodiment of the invention, the above advantages are achieved by using cryptographic value or identifier obtained in accordance with the method below. The identifier may be determined in the encoder by applying a one-way function to the group of one or more data frames. The frame typically includes data associated with a particular segment of the audio and / or video, for example with the segment comprising a predetermined number of discrete values of the media stream. For example, the frame of the audio stream may include 1024 discrete values of the audio data and associated metadata.
As mentioned above, to determine the identifier certain number of frames are grouped. The number of frames in each group may be selected by the encoder and is usually not known beforehand to the decoder. One-way function, preferably a cryptographic hash function HMAC-MD5 (hash message authentication code), although can be used instead of MD5 or other hash function such as SHA-1. A possible criterion for selecting an appropriate cryptographic hash function can be the size that should be small in order to reduce the overhead required for transmission. The size of the cryptographic hash function is generally given a number of its bits.
Once the identifier for the group of frames is calculated, for example, using the procedure of HMAC-MD5, it can be associated with the frame of the next GOP, for example inserted into the frame of the next GOP. As an example, the identifier may be recorded in the data field of the frame syntax element. Preferably, the identifier is inserted in the first frame of the next GOP. This allows to compute the identifier in the operation in a single pass without introducing additional latency into the encoder / decoder, which is especially useful for transmission of media data in real time. The data stream comprises an identifier may then be communicated to the appropriate receiver / decoder.
At the receiver, the inserted identifier can be used to identify an encoder authentication, verification, and / or configuration. The receiver generally includes a decoder that can be synchronized with a group of frames, i.e. it may define a frame including the identifier. On the basis of the distance between two consecutive frames, which include the ID, you can define the number of frames to the Group personnel, which was used to calculate the identifier. In other words, it may allow a decoder to determine the length of the group of frames without notice from the corresponding encoder.
The decoder can calculate the identifier for the received-frame. Identifiers, which are calculated based on the received-frame may be called Identity verification. If it is assumed that the identifiers are inserted into the first frame of the next group of frames, each frame group must begin with the first frame that includes an identifier for the previous group of personnel, and that it should end the frame that immediately precedes the next frame, which includes the identifier for the current Group personnel. The ID verification for the current group of frames can be calculated in accordance with the methods described above.
In the next step, the decoder can extract the identifier, transmitted by the encoder from a corresponding frame of the next GOP. Again, if the encoder identifiers are inserted into the first frame of the next GOP, the receiver also extracts this identifier from the first frame. This identifier is extracted from the data stream may be compared with the verification identifier, i.e. with an identifier that is computed by the decoder on the basis of the received data stream. If both IDs match, the decoder can generally assume that during the transmission error does not have any group of frames is done unaffected frame group has not been modified during the transmission and the frame group is received from a trusted and / or the legitimate encoder. Furthermore, if both IDs match, the decoder can choose to unlock one or more possibilities, depending on the codec, or improvements that would not be permitted in decoding the random bit stream. For example, additional features can be resolved if the bit stream decoder identifies specific for Dolby Pulse, whereas these additional features would not be visible to the encoded bit stream standard HE-AAC v2. Nevertheless, the decoder may be able to decode the encoded bit stream standard HE-AAC v2 but without additional functions.
It should be noted in addition that the identifier may be allowed to install software in the decoder configuration corresponding correct decoding and / or playback of the media stream. In these cases, the coincidence of the ID verification and transmitted identifier must point to the fact that the decoder uses the correct configuration settings.
If, on the other hand, identifiers, i.e. ID verification and transmitted identifier does not match, the decoder will know that in the course of transmission error occurred, a group of staff had not been adopted intact, the frame group was modified during transmission or group of frames not transmitted from a reliable encoder. In these cases, the decoder may be fully blocked or, alternatively, can be blocked by specific features or improvements.
It should be noted that the identifier can also be used to inform the decoder that set incorrect configuration. In these cases, the discrepancy between the identifier and the identifier of the verification may be associated with the fact that the decoder uses wrong configuration, even if the frame group adopted intact and reliable from the encoder. It can be provided that in these cases, the decoder can act to modify its configuration settings, and to determine the appropriate identifiers to verify until verification identifier will not match the transmitted identifier. This modification can provide the decoder to set its actual configuration in accordance with the received bitstream.
The following describes the various features of the proposed method. According to a first aspect, discloses a method of encoding a data stream comprising a number of data frames. Data streams can be a stream of audio, video and / or other media and multimedia data. In particular, the data streams may represent data flows Dolby Pulse, AAC or HE-AAC. Data streams are usually arranged in data frames which include a certain number of discrete values of the data and covering a certain segment of the data stream. For example, the frame 1024 can include discrete values of an audio signal sampled at 44.1 kHz sampling frequency, i.e. it covers a segment of about 23 ms. It should be noted that the discrete values can be encoded with constant or variable bit rate, and the actual number of bits per frame may vary.
The method may include the step of grouping a number of N consecutive data frames to generate the first message. The number N of successive data frames, is typically chosen in accordance with considerations of the overhead data rate. Typically, the overhead decreases as the number N. N is preferably greater than unity. Typical values of N are about 20. In a preferred embodiment, N may be chosen so that N consecutive frames coated with 0.5 seconds during playback of the corresponding signal corresponding decoder with the corresponding configuration of the decoder. It should be noted that the grouping step can include the concatenation of N consecutive frames in their natural, i.e. threading order.
The next step is the first message can be grouped together with the configuration information for the formation of the second message. This configuration information includes information of data stream is that, generally refers to a data stream, in particular, is information for rendering the data stream at the receiver side. The configuration information may include information relating to setting the appropriate receiver and / or decoder to use for processing the data stream. Since this configuration information usually is not transmitted, or is not included in the data stream, it may also be called out-band data as opposed to a data stream which can also be called in-band data.
Configuration information can be grouped in various ways with the first message. It can be concatenated with the first message, i.e. placed at the beginning and / or end of the first message. Configuration information can also be located at certain positions within the first message, for example some or all consecutive frames.
Typical examples of the configuration information includes a pointer to the sampling frequency, which is used in the sampling base analog stream media. Configuration information can also include a pointer to the channel configuration of audio coding, such as a mono channel configuration, 2-channel stereo configuration, or 5.1 surround sound configuration. Configuration information also may include a number of discrete values of the pointer in the data frame, for example 960, 1024 or 2048 discrete values relating to a data frame.
Also, the method includes the step of generating the cryptographic values for the first and / or second messages. A cryptographic value may also be called an identifier. Said cryptographic value may be generated using a key value and a cryptographic hash function. In particular, a cryptographic value may be generated by computing the HMAC-MD5 values for the first and / or second messages. Moreover, the generation of the cryptographic values may include truncation value HMAC-MD5, for example truncation to 16, 24, 32, 48 or 64 bits. This can be useful in view of reducing the overhead required for the cryptographic values in the data stream.
Additionally, the method includes inserting the cryptographic values in the data stream after the N successive data frames. Preferably, the cryptographic value is inserted in the first frame following the N successive data frames in order to allow its rapid decoding and verification and authentication in the coder corresponding decoder. It may also be useful to insert pointer synchronization after N successive data frames, where a pointer points to insert synchronization cryptographic value. Said pointer synchronization may be adjacent to a cryptographic value, allowing conveniently retrieve cryptographic value corresponding to the decoder.
In an exemplary embodiment, the data stream is a stream or MPEG4-AAC MPEG2-AAC, and the cryptographic value is inserted as an element <DSE> data stream. Said element <DSE> data stream may be inserted into the front end of the frame element <TERM>. Furthermore, the content of said element <DSE> data stream may preferably be aligned on a byte boundary data stream in order to facilitate the extraction of the element <DSE> data stream, in particular the cryptographic values and / or index corresponding decoder synchronization.
It should be noted that the step of generating a cryptographic value may preferably be performed iteratively on separate frames group of N consecutive frames. To this end, for each of the N successive frames using the initial state can be generated cryptographic intermediate value. Initial state may be an intermediate cryptographic value of the previous iteration. For example, intermediate cryptographic value may be generated for the first frame. This intermediate cryptographic value may then be used as the initial state for generating a cryptographic value of the second intermediate frame. This process is repeated until until cryptographic value generated intermediate N-th frame. This latter intermediate cryptographic value usually is a cryptographic value for the group of N consecutive frames. In order to take into account the configuration information, the initial state of the first iteration may be an intermediate value for the cryptographic configuration information.
In a preferred embodiment, a cryptographic value for the block of N consecutive frames of data is generated on a block of N consecutive data frames comprising a cryptographic value for the previous block of N consecutive data frames. Thus, there may be generated a stream of related cryptographic variables.
According to another aspect, the method may include the step of interaction with the video and / or audio coder data stream. This step can be implemented by performing encoding video and / or audio, as well as the generation of the cryptographic values in an integrated manner. In particular, the interaction between the video and / or audio coder data stream and generating a cryptographic value may be directed to setting the maximum bit rate for video and / or audio encoder such that the bit rate data stream including a cryptographic value that does not exceed predetermined value. This may be particularly useful if the underlying data stream codec sets a higher limit bit rate allocation for the full data stream.
According to a further particularly describes a method for verifying the data flow in the decoder and / or receiver. It should be noted that the disclosed methods and systems may be used in the context of transmission data streams, and data streams is provided on the data carrier. As described above, the data stream typically includes a number of data frames and a cryptographic value associated row of the previous N consecutive data frames. It should refer to the discussion made in this document, particularly in respect of the possible values of N, and the structure of the data stream and frame.
The method includes the step of extracting N successive data frames to generate the first message. The method may also include the step of determining the value of N. This step can be performed in a data stream which includes a number of N successive data frames and associated cryptographic value. If N consecutive frames of data called a group of frames, said data stream typically includes a number of groups of frames and the cryptographic values associated with each of the groups of frames. In these cases, the number N may be defined as the number of frames between two successive cryptographic values.
Note that the current group of frames is used to calculate the second cryptographic value may include a cryptographic value for the previous group of frames. In an alternative embodiment, the cryptographic value to the previous-frame and any associated pointer synchronization and / or syntax element must be removed from the current group of frames before calculating a second cryptographic value. The latter solution may be preferable in order to prevent changes and deviations from the spread in the transition from one group to the next frame.
The method may also include the step of grouping the first message with the configuration information to form a second message, wherein the configuration information typically includes information stream is data such as information to render the data stream. Stage grouping and various characteristics pertaining to the configuration information described above. These features are equally applicable to the decoder.
The method continues by generating a second cryptographic value to the first and / or second message by retrieving cryptographic values from the data stream, and comparing the cryptographic values from the second cryptographic value. Second cryptographic value may also be called a cryptographic value for the verification, or verification identifier.
It should be noted that the second cryptographic value may be generated in an iterative manner as described in the context of generating a cryptographic value.
In a preferred embodiment, the cryptographic value is generated in the relevant encoder and / or the transmitter of the N successive data frames, and information about the configuration according to the method corresponding to the method used to generate a second cryptographic value. In other words, a method for generating a cryptographic value corresponding to the encoder corresponds to the second method for generating the cryptographic values in the decoder. In particular, a cryptographic value and a second cryptographic value generated using the unique key values and / or unique cryptographic hash function.
In addition, a set of N consecutive frames used for generating the cryptographic values in the encoder corresponds to a set of N consecutive frames used for generating the second value in the cryptographic decoder. As mentioned above, the cryptographic value and a second cryptographic value may be determined on a set of N consecutive frames, which include or do not include a cryptographic value for the previous set of N consecutive frames. The same rule should apply to the encoder and decoder.
Even if a set of frames used in the encoder and decoder must be identical, it should be noted that the contents of frames in the encoder and decoder can vary, for example because of modifications that frames exposed during their transmission, or because of errors on the media data stream .
According to a further aspect, the method may include the step of setting a flag in a case where cryptographic value corresponding to the second cryptographic value and / or the step of providing a visual indication of the receiver and / or decoder, if the flag is set. Similarly, a flag and / or visual indication may be deleted if the cryptographic value is not corresponding to the second cryptographic value or if the cryptographic value can not be extracted from the data stream. It may be useful to provide the user of the decoder, and the viewer / listener's data stream of information about the authenticity of the data stream.
According to another aspect, a data stream is described, comprising a cryptographic value generated and inserted in accordance with the methods described in this patent document.
According to another feature described encoder operative to encode a data stream comprising a number of data frames. The encoder operates to perform the steps of the method described in this patent document. In particular, the encoder can include a processor operating on a group of N number of consecutive frames of data to generate the first message; where N is greater than one; for grouping the first message with the configuration information to form a second message; wherein configuration information includes information stream is data such as information to render the data stream; generating a cryptographic value of the second message; and to insert cryptographic values in the data stream following the N successive data frames.
According to the following features described decoder operable to verify the data stream including a series of frames of data and a cryptographic value associated with the number N of consecutive preceding frames of data, where N is greater than one. The decoder operates to perform the steps of the method described in this patent document. In particular, the decoder may include a processor operative to retrieve N successive frames of data to generate the first message; for grouping the first message with the configuration information to form a second message; wherein configuration information includes information for rendering the data stream; generating a second cryptographic value of the second message; to retrieve cryptographic values from the data stream; and for comparing the cryptographic value to the second cryptographic value.
According to the features described in the following program is implemented in software. The program is implemented in software adapted for execution on a processor for performing the steps of the method described in this patent document, the implementation on a computing device.
According to a further particularly described storage medium. The storage medium includes a program implemented in software, which is adapted for execution on a processor for performing the steps of the method described in this patent document, the implementation on a computing device.
According to a further particularly described computer program product. The computer program product comprises executable instructions for performing the steps of the method described in this patent document, the implementation on a computer.
According to the following described additional features of the external device, the portable electronic device (e.g., mobile phone, PDA, smart phone, etc.) or a computer (e.g., desktop, laptop, etc.), for decoding the data stream. The data stream may include an audio signal. Additional external device preferably includes a decoder corresponding to the features described in this patent document.
According to a further particularly described broadcast system for transmitting the data stream. The data stream may include an audio signal. The broadcasting system preferably includes a coder corresponding to the features described in this patent document.
According to another aspect, it discloses a method of concatenation of the first and second bit streams at the point of concatenation. Each of the two bitstreams may comprise a plurality of data frames and a cryptographic value associated with a predetermined number of data frames. The first bit stream may include a cryptographic value for every N1 successive frames, while the second bit stream may include a cryptographic value for each successive frame N2. The numbers N1 and N2 may be identical, i.e. the two bitstreams have the same repetition period cryptographic or numbers N1 and N2 may be different, i.e. the bit streams may vary the number of frames after which includes cryptographic value.
A method of concatenating comprises the step of generating a concatenated bit stream from the first and second bitstreams, wherein a concatenated bit stream comprises at least a portion of the series of data frames from the first and second bitstreams. In other words, the second bitstream or the second bitstream part is attached at a point of concatenation to the first bit stream or the first part of the bitstream.
Concatenated bitstream includes cryptographic values generated and inserted in accordance with the methods described in this patent document. Advantageously, the cryptographic values in the bitstream concatenated smoothly coated concatenation point so that the receiver / decoder was not noticeable interruption authenticity bitstream. This may be achieved by generating an explicit new cryptographic values for the concatenated bit stream after the point of concatenation.
New cryptographic values may be generated at least for a number of consecutive frames in the section of the concatenated bit stream starting at the point of concatenation. In some cases, the cryptographic value of the second bit stream may be re-used and copied into concatenated bit stream after the section, which includes new cryptographic value. Such reuse is applied, in particular, when a cryptographic value for the previous group of frames included in the first frame of the next group is not considered in the calculation of the cryptographic values of the group, and the groups are processed independently, i.e. changes in the cryptographic values are not spread from one group to the next.
Generation of cryptographic variables explicitly in accordance with the methods described in this patent document may be practically useful at the boundaries between the first bit stream and the second bit stream, i.e. end of the first frame and the bit stream for the first frame of the second bitstream, included in the concatenated bit stream. In general, when the concatenation of two bit streams of the first frame number of the final bitstream, typically less than or equal to N1, and / or the number of frames taken from a second bit stream before switching a first cryptographic value is usually less than or equal to N2. In other words, the point of concatenation, as a rule, is not located at the boundaries of the first and second groups of bit streams.
In one aspect, a method of concatenating the compound or new cryptographic value is generated for the final frame of the first bitstream and the next frame is inserted into concatenated bit stream which represents the first frame, taken from the second bitstream. This new cryptographic value is considered "final" first bitstream. New cryptographic values may then be generated for the second bit stream and incorporated into the corresponding position of the concatenated bit stream. This is particularly useful in cases where no additional cryptographic value inserted in the first frame, taken from the second bit stream, the number of frames between the last cryptographic value generated for the frame of a first bitstream and a first cryptographic value generated for the frames of the second bit flow would exceed the maximum number permitted by the system.
In case the concatenation point is not aligned with the groups of frames of the first and second bitstreams, the method of concatenation may generate a cryptographic value for the mixed group consisting of pictures taken of the first and second bitstreams. As already mentioned, the cryptographic values are typically included in the frame following the frame group used for the calculation corresponding cryptographic value.
According to another particular describes a device for concatenation and / or head-end broadcast. Said device for concatenation and / or head-end broadcasting operates to concatenate the first and second bit streams, each of which includes a number of data frames and a cryptographic value associated with a predetermined number of data frames. The apparatus may include a decoder comprising any combination of characteristic features described in this patent document. Said decoder may be used for decoding of final frame of the first bitstream, the first frame of the second bitstream and associated cryptographic variables. An apparatus for concatenating and / or head-end broadcast network may also include an encoder, comprising any combination of characteristic features described in this patent document. The encoder can be used to encode the final bit stream of the first frame and the first frame of the second bitstream. Furthermore, an apparatus for concatenating and / or broadcasting network headend can switchable flow redirection designed to redirect the frame and associated cryptographic values of the first and second bit streams are not decoded and encoded. In other words, the unit can simply copy the promotion, or redirect, or transfer, personnel and related cryptographic values in the concatenated bit stream.
It should be noted that the device for concatenation may also act to complete decoding and encoding data streams, i.e. for decoding the cryptographic values of the incoming data stream and for generating a cryptographic value for the outgoing data stream. It may be useful to generate a continuous bitstream through interconnection cryptographic variables. In fact, the number of bit streams may be decoded and concatenated bit stream, comprising part of a series of bit streams may be encoded by continuously interconnected cryptographic variables. Thus, the receiver concatenated bit stream is taken as a concatenated bit stream bit stream derived from a single encoder, trustworthy.
It should also be noted that for the purpose of decoding and / or coding bitstreams comprising cryptographic values apparatus for concatenation may not feel the need to be aware of the basic data stream codec. For example, the device does not need to be concatenated in the possibility of performing decoding / encoding HE-AAC to retrieve and / or generate cryptographic values for the data streams. In some situations, such as when a new cryptographic value is inserted into the frame, which previously did not contain cryptographic value decoding and subsequent re-encoding of the data stream can be necessary to create the bit stream of free space for a new cryptographic value, particularly to meet requirements bitstream.
It should be noted that the methods and systems, including the preferred embodiments of the invention in the form as they are described in this patent document may be used alone or in combination with other methods and systems described herein. Also, all features of the methods and systems described in this patent application may be combined arbitrarily. In particular, features of the claims may be arbitrarily combined with each other. It should also be noted that it may change the order of method steps.
DESCRIPTION OF THE DRAWINGS
The invention is explained by examples, with reference to the accompanying drawings, wherein
FIG. 1 - an illustrative method for determining an identifier in accordance with the invention;
FIG. 2a and 2b - flowchart of an exemplary method for generating an identifier, and inserting it in the encoder;
FIG. 3 - a flowchart of exemplary steps for authentication and verification taken into the decoder;
FIG. 4 - an exemplary embodiment of an encoder and decoder;
FIG. 5 - an example of an identifier in a broadcasting system; and
FIG. 6 and 7 - Examples concatenation of bit streams to form a concatenated bitstream.
The following embodiments are described in the examples and do not limit the scope of the patent document. The invention will be described in the context of the AAC (Advanced Audio Coding), in particular the MPEG-2 AAC and MPEG-4 AAC. It should be noted, however, that the invention is also applicable to other coding schemes media signal, in particular to audio coding schemes, video and / or other multimedia signals. Furthermore, the invention is applicable to a device for concatenation create a combined bit stream of a number of encoders.
FIG. 1 illustrates a bitstream 100 and a method for determining an identifier of the bit stream 100. Examples of such a bit stream of coded bits are video and / or audio streams to the base codec AAC, HE-AAC (High Efficiency - Advanced Audio Coding), Dolby Pulse, MPEG- 4 AVC / H.264, MPEG-2 Video or MPEG-4 Video. These codecs and their format is determined, for example, in the description of the standard ISO / TEC 14496-3 - MPEG-4 AAC, in the description of the standard ISO / IEC 13818-7 - for MPEG-2 AAC, in the description of the standard ISO / IEC 14496-10 - MPEG-4 AVC / H.264, in the description of the standard ISO / IEC 13818-2 - for MPEG-2 Video standard and specification, ISO / IEC 14496-2 - MPEG-4 Video. These references include descriptions herein. In such codecs the data streams are organized in so-called frames, where the frames include a certain number of discrete values mediasignala. Various codecs may use different number of discrete values attributable to frame. Typical examples are the amounts of 960, 1024 or 2048 discrete values per frame.
In addition to the actual media data frames may also include so-called metadata that may carry additional control information, for example relating to the volume or the dynamic range of the program.
FIG. 1 shows a sequence of frames 101, 102, 103, ..., 106. The time axis runs from left to right, so the frame 101 is processed before the frame 106. As described above, each frame may include media data and additional metadata. The structure of each frame and possible fields or items of data that may comprise a frame defined by a base coding scheme. For example, the frame of MPEG-4 AAC or MPEG-2 frame may include AAC audio data for the time period containing 960 or 1024 discrete values, related information and other data. The syntax and frame structure defined in sections 4.4 and 4.5 above description of the standard ISO / IEC 14496-3 - MPEG-4 AAC, and in sections 6 and 8 of the above description of the standard ISO / IEC 13818-7 - for MPEG-2 AAC. These sections include reference herein.
Still MPEG-4 AAC, or MPEG-2 AAC, can include different syntax elements, such as:
Element single_channel_element (), abbreviated SCE, which is a syntax element of a bit stream containing encoded data for a single audio channel.
Element channel_pair_element (), abbreviated CPE, which is a syntax element payload bitstream containing encoded information for a channel pair.
Element coupling_channel_element (), abbreviated CSE, which is a syntax element containing encoded audio data for the associated channel.
Element lfe_channel_element (), abbreviated LFE, which is a syntax element comprising a channel increasing low frequency sampling.
Element program_config_element (), abbreviated as PCE, which is a syntax element that contains data about the program configuration.
Element fill_element (), abbreviated FIL, which is a syntax element that contains data entry.
Element data_stream_element (), abbreviated DSE, which is a syntax element that contains the auxiliary data.
Syntax elements TERM, indicating the end of the raw data block or frame.
These syntactic elements used within a frame or a block of raw data to determine the media data and associated control data. For example, two frames of the mono sound signal can be determined by syntax elements <SCE> <TERM> <SCE> <TERM>. Two frames stereo audio signal can be defined syntactical elements <CPE> <TERM> <CPE> <TERM>. Two frames with 5.1-channel audio signal can be defined syntactical elements <SCE> <CPE> <CPE> <LFE> <TERM> <SCE> <CPE> <CPE> <LFE> <TERM>.
The proposed method includes a certain number N of frames, and thus forms a group of frames 111, 112 and 113. In FIG. 1 shows a full frame group 112, including N = 5 frames from 103 to 105. Five staff-frame 112 are concatenated to form the first message.
Hash Message Authentication Code (HMAC) for the first message may be determined using a cryptographic hash function H (.) And a "secret" key K, which is usually filled to the right with additional zeros to the block size of the hash function H (.). Let the symbol || denotes concatenation, sign denotes the exclusive-OR and the outer padding and inner filling are constants having the block size length hash function H (.), then the HMAC value to the first message can be written as
<IMG>
<IMG>
<IMG>
.
<IMG>
where m - the message, also referred to herein as the first message. The block size used hash functions MD5 or SHA-1, as a rule, is 512 bits. Size HMAC output operation is the same as that of the base hash function, i.e. 128 bits - for MD5, 160 bits, and - in the case of SHA-1.
HMAC value for the first message, ie HMAC value concatenated frames 103-105 GOP 112 can be used as an identifier-frame 112. In order to reduce the length of the identifier value may be truncated HMAC, truncated to example 16, 24, 32, 48 or 64 bits. It should however be noted that this truncation usually affects safety hash message authentication code. Since the identifier is inserted into the data stream, the proposed method is preferably used as an identifier truncated version of HMAC value.
As shown in FIG. 1, identifier 122-frame 112 is inserted into the frame of the next GOP 113. Preferably, the identifier 122 is inserted into the first frame of the next GOP 106 113. Likewise, the identifier 121 has been determined for previous-frame 111 and inserted into the first frame of the frame group 103 112 .
It should be noted that the identifier 122-frame 112 can be calculated based on the first message m, which includes the group identifier 121 of the previous frame 111, or it can be computed on the basis of the first message m, which does not include a group identifier 121 of the previous frame 111. In the latter case, information related to the identifier 121 to be removed from the first message m before determining the identifier 122. It may be necessary to ensure that the encoder and decoder applies the same method to determine the first message m. In a preferred embodiment, the identifier 122 is determined based on the first message m, which includes the identifier 121 of the previous-frame 111. Thus, the identifiers may be interconnected and continuous, respectively, can be interconnected to create a bit stream which can not be modified, for example by modification or replacing certain groups of frames of the bit stream. As a consequence, it is possible to ensure the authenticity of the complete data stream or bit stream. C on the other hand, still it is possible to resynchronize the receiver to the partially corrupted bit stream, even in the case where the identifiers are interconnected.
In a preferred embodiment, the identifier is placed in the unit element data_stream_element (), abbreviated as <DSE> and defined in the standard ISO / IEC 14496-3, 4.10 - MPEG-4 AAC, or defined in standard ISO / IEC 13818-7, Table 24 - for MPEG-2 AAC, which reference is incorporated herein. To facilitate synchronization of the decoder, AAS frame should include only one element data_stream_element () <DSE>, carrier ID, so the decoder may determine the length of the GOP as the distance between two received identifiers. In other words, the frame may include a plurality of AAS elements data_stream_element () <DSE>, but should include only one element data_stream_element () <DSE>, comprising the identifier. In a preferred embodiment, the position <DSE> is at the end of the frame immediately before the element AAS <TERM>.
In order to enable quick retrieval of an identifier can be used to equalize the DSE function on a byte boundary. C DSE this purpose, generally includes a field or a bit that indicates that the data included in the DSE, are aligned on a byte boundary. This indicates to the decoder that starts the actual data DSE at bit position at the beginning of a byte.
Bitstream, or stream data may include multiple items <DSE>. In order to be able to distinguish one element <DSE> from each other, each element <DSE>, typically includes a label element_instance_tag, defined for MPEG-4 AAC standard ISO / EEC 14496-3, section 4.5.2.1.1, and for MPEG-2 AAC - standard ISO / IEC 13818-7, Section 8.2.2, both the reference section included herein. It should be noted that the value of the label member element_instance_tag data_stream_element (), including the identifier is not limited to any particular size, i.e. the general rules of standards ISO / IEC. In other words, preferably there are no specific rules to tags in element_instance_tag element <DSE>, containing an identifier other than those set for the MPEG-4 AAC standard document ISO / IEC 14496-3, and the MPEG-2 AAC - a standard document ISO / IEC 13818-7.
By analogy with the above examples of possible data flow, data stream for 2-channel audio programs may include syntax elements <CPE> <FIL> <DSE> <TERM> <CPE> <FIL> <DSE> <TERM> .... 2 -channel audio program with the SBR (Spectral Band Replication) may include syntax elements <CPE> <SBR (CPE)> <FIL> <DSE> <TERM> <CPE> <SBR (CPE)> <FE> <DSE> <TERM> ... where <SBR (CPE)> - syntax element specific to the SBR. 5.1-channel audio program may be composed of syntax elements <SCE> <CPE> <CPE> <LFE> <FIL> <DSE> <TERM> <SCE> <CPE> <CPE> <LFE> <FIL> <DSE> < TERM> ....
In a preferred embodiment, the identifier field to be placed in the element <DSE>, may include the field and the field identifier_sync identifier_value. Identifier_sync field can be used to allow the quick identification on the basis that this particular element of <DSE> contains an identifier. For example, the encoder may set the predetermined value of this field, for example, a binary output signal to indicate that the element <DSE> includes an identifier field. The decoder can use this field to check the availability of ID values. In other words, the decoder is informed that the received data stream comprises an identifier, which can be used for the purpose described above, authentication, verification and possible configuration.
In a preferred embodiment, the field comprises identifier_value identifier value that is determined as described herein. This field includes the number of bits required for the identifier, i.e. for a truncated version of the HMAC value. As described above, the ID is usually covers AAS N frames, where N> 1, and each N-th frame comprises an identifier of AAS, i.e. it includes an element <DSE>, which includes element ID as described above. Typically, the decision on the number N of frames covered AAC encoder receives. The decoder is able to determine this value expressed in frames of the distance between the two frames AAS, including the corresponding identifiers.
As described above, the identifier may also be used to ensure that the decoder used the correct configuration. For this purpose, an identifier may be generated based on the augmented message, which includes not only the concatenation of N consecutive frames, but also includes configuration data. In other words, the first message that includes the N consecutive frames, as described above, may also include configuration data. Such configuration information may include index samplingFrequencyIndex, ie the pointer base sample rate audio signal, the index channelConfiguration, ie Index your configuration channels and flag frameLengthFIag, ie Index used the length of the frame. Also, there are other configuration options.
These parameters, i.e. (base) sampling frequency AAS or «samplingFrequencyIndex», channel configuration and length indicator AAC transform, or "frameLengthFIag", can be used to form words configuration_word. Word configuration_word can also include filler bits in order to bring it to a predetermined size.
In a preferred embodiment, the parameters "samplingFrequencyIndex" and "channelConfiguration" have the same meaning and value as the elements of the same name in the "AudioSpecificConfig", described in the corresponding description of ISO / IEC (e.g., section 1.6.2.1 of ISO / IEC 14496 -3). Parameter "frameLengthFIag" has the same meaning and the value of that element in the self-titled "GASpecificConfig", as described in the corresponding specification of the standard ISO / IEC (for example, in section 4.4.1 and Table 4.1 of the standard ISO / IEC 14496-3).
Word configuration_word and N concatenated AAC frames, giving a message m, which can also be called a second message and that includes the word configuration_word in addition to the first message that includes concatenation of N frames AAS:
;
<IMG>
where || denotes concatenation. In the above example the word configuration_word located before the first message. It should be noted that the word configuration_word may also be placed in other positions, for example at the end of the first message.
Similarly HMAC value described above, for example code HMAC-MD5, HMAC (m) on a message m is calculated using the "secret" key K. The key K may for example be a predetermined ASCII code or other secret value, and the value for the message HMAC m is calculated using the above formula for HMAC.
It should be noted that the value HMAC for message m can be determined sequentially. This means that in the first stage may be determined by the value for the HMAC word configuration_word. This leads to a first HMAC value as the initial state to determine the value for the frame 1 HMAC AAS. The output signal of the second operation is the HMAC value to the frame 2 AAC, etc. Ultimately, using as the initial state values for HMAC frame N-1 is determined by AAS HMAC value for frame N AAS. Using a consistent definition of HMAC values for the entire message m, that is throughout the sequence of frames and / or word configuration_word, the identifier can be generated without increasing the delay introduced into the bitstream. Moreover, the memory requirements for generating a HMAC value and / or the identifier kept low, since the need to store in memory only the present frame and the bit stream of the initial state, i.e. 128-bit value. The generation and storage of a complete message m is required.
In order to reduce overhead in the bitstream, cause additional identifier value is HMAC is truncated from 128 bit to a reduced number of bits by discarding the least significant bit. For example, the HMAC "9el07d9d372bb6826bd81d3542a419d6" may be truncated to "9el07d9d". The degree of truncation is preferably chosen as a compromise between security identifier and the overhead for the required bit rate. Possible length identifier may for example be 16, 24, 32, 48, 64, 80 or 96. The truncated HMAC is an identifier that is inserted in the identifier_value element DSE.
The following provides further details relating to the encoding process. As already mentioned, this encoder typically decides the number of N frames AAS, which are covered by one identifier. For example, it may be desirable to provide the ability to synchronize the decoder with the length of the group of frames within no more than 1 second. Since the two identifiers need to be synchronized with the decoder to-frame length, which is given by the number of frames between a frame including an identifier is necessary to ensure that the decoder will, at least two identifiers within a specified time interval. Therefore, the encoder should select the value of N so that N frame time representation AAG does not exceed or minimally exceed 0.5 seconds. Since the time representation of the N frames AAC depends on the (base) sampling frequency AAS value N, the selected encoder may vary depending on the chosen (base) sampling frequency AAS.
In order to minimize the bit rate overhead data introduced identifier, an encoder can choose the largest value of N, which satisfies the constraint which is that the time representation AAS N frames must not exceed 0.5 seconds. In some applications for temporary representation N frames AAS permitted a slight excess of 0.5 seconds. In these applications, the encoder can select a value of N so that N frame time representation AAS was maximally close to 0.5 seconds, even if in some cases may lead to a time representation N frames AAS somewhat exceeds 0.5 seconds. Overhead which made transmission identifier may be determined by estimating the ratio between the length of the element DSE, including an identifier and a total length of a group of frames (in number of bits).
In addition, it is recommended to align the rate identifier insert other configuration items such as title SBR. This allows you to easily synchronize the decoder with the bit stream, and also allows you to take all the configuration word during the decoding of a single frame.
It should be noted that the first generated frame AAS may contain false ID. The purpose of the first identifier may be a transmission decoder signal the beginning of a sequence of frames AAS including identifiers. However, the decoder may not be in a position to perform authentication and verification because the identifier can not be based on actual media.
As described in relation to FIG. 1, the first identifier calculated covers AAC frames 1 to N and stored in the frame N + 1 AAS. Next identifier covers AAC frames from N + 1 to 2N is stored in a frame and 2N + 1 AAS, etc.
FIG. 2a illustrates a flowchart of the encoding process. In step 201, the encoder is initialized by providing a certain amount of N frames, consisting in group shots. Furthermore, provided the key K. In the next step 202, the N frames in the group of frames are concatenated to create the first message. Then in step 203 is concatenated with the first message word configuration allowing the second message. In step 204 is determined identifier in the form of a truncated version of HMAC value calculated by the second post. This identifier is placed in the first frame of the next group of frames (step 205). Finally, in step 206, the group of frames being transmitted. It should be noted that the transmitted frame group includes a group ID frames transmitted in front of her. Steps 202-206 are repeated until then, until it is handed over to the full stream of data.
As already mentioned, the above process may be performed in an iterative manner consistent. This means that the identifier may be determined without the need for modal provisional concatenating N frames and words configuration_word and performing HMAC calculation in this fully concatenated message. This process is illustrated in FIG. 2b. The iterative procedure is initialized at step 207 by setting the initial state. The initial state may be a HMAC value for configuration_word word, which is stored in the memory of 128 bits. Then HMAC value may be determined for the first of the N frames (step 208). HMAC result value is stored in memory 128 bits (step 209) and used as the initial state for computing HMAC value of the second frame (step 208). This process is repeated until, until it is determined HMAC value for the N-th frame, where HMAC value for the N-1 th frame is taken from the 128 bits of memory and is used as the initial state (step 208). The identifier is defined as a truncated version of HMAC value for the N-th frame (step 210). Alternatively, step 206, each frame may be sent immediately after processing to compute HMAC value without buffering entire-frame. The identifier is then added to the N + 1 th frame, and this frame is sent. Thus, this frame is the first frame that is used for iteratively computing HMAC value for the next N frames. Using this process, the encoding process can be done frame by frame, low-latency, low computational complexity and low memory requirements.
Following are further details relating to the decoding process. Typically, the decoder begins with the assumption that the stream to be decoded does not include an identifier having a force. Those. pointer presence force having media stream identifier bit is initially set to "false" and, as a rule, will be set to "true" only when successfully receiving the first power having the identifier. It can be shown on a receiver, such as an optional external device via a visual indicator, such as an LED, which indicates to the user that the received bit stream is authenticated and has the force bitstream. As a consequence, an identifier may be used to indicate to the user the quality of the received data stream.
On the other hand, if the pointer to the decoder is set to "true", but more frames than Nmax offline update identifier with respect to the bitstream, the pointer can be set to "false". In other words, the decoder may become aware of the maximum value N, e.g., Nmax, is not exceeded. If the decoder does not detect a force having an identifier for more than Nmax frames, it indicates to the decoder that the received bit stream is no longer derived from legitimate encoder or the received bit stream may have been altered. As a consequence, the decoder sets the appropriate pointer to the value "false". This may lead to the fact that the visual indicator, such as LED, generally returns to its original condition.
Identifier decoding procedure illustrated in Fig. 3 and may be described as follows:
• At 300, the decoder starts and resets the flag "ID Verified".
• Then in step 301 is initialized (128-bit) status of the internal memory.
• At step 303, the decoder waits for the reception frame (step 302) and checks for the presence of the received frame identifier bitstream. Availability identifier in the frame can be detected by the above-described field identifier_sync. In step 307, if the identifier has been detected in step 304, the decoder retrieves identifier_value from the corresponding field in the <DSE>.
• then in step 308 by truncating values HMAC contained in the 128-bit state is generated verification identifier.
• decoder continues operation at step 309 by comparing the identifier with an identifier bitstream verification. If it is determined that the ID is not equal to two (step 310), at step 311 the flag "ID Verified" is reset, indicating that there is no bitstream from the encoder, trustworthy. In the case of identical ID at step 312 sets a flag "ID Verified", indicating that the identifier is verified and that the bit stream is considered to have an effect, since it comes from the encoder trustworthy. In this case, it can be released more decoder functions, and / or the user can be informed about the status of the verification bit stream. Alternatively, some functions can be blocked if it is determined that there is no bitstream from the encoder, credible, and / or the user may be informed accordingly.
• The decoding process continues at step 313 by initializing the 128-bit internal state memory.
• Then in step 314 is calculated 128-bit value HMAC for the current frame, and at step 315 a 128-bit state of the internal memory is updated with the computed value HMAC. The decoder then returns to step 302 to await receipt of the next frame.
• If no specific frame identifier (determined in step 304), the decoder proceeds to step 305, where the decoder determines whether the identifier present in one of the last Nmax frames.
• If the identifier missing in one of the last Nmax frames, the decoder at step 306 resets the flag "verified ID", taken as the maximum number of frames Nmax, elapsed without an identifier. The decoder then returns to step 302 to wait for the next frame.
• If the identifier is present in one of the last Nmax frames, as determined in block 305, the decoder proceeds to step 314 to compute a 128-bit value HMAC for the current frame.
As described above, the decoder can determine the identity verification during successive iterative process. This means that only the currently processed frame, and there is no need to concatenate first set of frames to determine identity verification. Accordingly, the decoding of the identifier may be performed with a low latency, low computational complexity and low memory requirements.
FIG. 4 shows an exemplary embodiment of an encoder 400 and decoder 410, the data stream. The analog data stream 405, such as an audio stream is converted into a digital data stream 406 using an analog-digital converter 402. The digital data stream 406 is encoded using an audio encoder 403, such as Dolby E, Dolby Digital, AAC, HE AAC, DTS or Dolby Pulse. The audio encoder 403 are usually digital data stream segments 406 in the sound signal frame, and performs data compression. In addition, the audio encoder 403 can perform the addition of metadata. The output of the audio encoder 403 is a data stream 407 comprising a series of frames in the audio signal. Then, the data stream 407 included in the additional frame encoder 404 that adds data to the stream identifier 407 or cryptographic value. The encoder 404 staff operating in accordance with the features described in this patent document. Note that the identifiers are usually detected and added sequentially, and thus each frame coming from the audio encoder 403, the encoder 404 directly processed frames. Preferably, the audio encoder 403 and encoder 404 form a combined frame encoder 401 that may be implemented on a digital signal processor. Thus, features of the audio signal coding and generate a particular identifier can influence each other. In particular, in the audio coding may take account of additional overhead due to ID. This means that the available bit rate for the audio stream bit can be reduced. Such interaction between the audio coder and generating the identifier may be used to match the total bandwidth and / or limiting the bit rate of data transmission in some coding schemes, such as HE-AAC.
Combined encoder 401 outputs a data stream 408 comprising a number of groups of personnel and associated identifiers. The data stream 408 is typically fed to the associated decoder and / or receiver 410 using different transmission media and / or media. It reaches a decoder 410 as a data stream 418 that could be changed relative to the data stream 408. Data stream 418 included in the frame decoder 414, which performs authentication and verification data stream 418 in accordance with the methods and systems described in this patent document. The decoder 414 outputs the stream data frame 417, which generally corresponds to the data stream 418 without identifiers and the corresponding data field or syntactic elements. The data stream 417 is decoded in the audio decoder 413, where it is unpacked and where deleted metadata added. As described above, the decoding of frames is usually performed by sequentially iterative way and thus processing is performed frame by frame.
It should also be noted that the various components of the decoding / reception can be grouped together to form a combined decoder. For example, the frame decoder 414 and audio decoder 413 may form a combined decoder / receiver 411, which may be implemented on a digital signal processor. As described above, it may be useful to allow interaction between the implement and the audio decoder verification identifier. Ultimately, a combined decoder / receiver 411 outputs data stream 416, which is converted into an analog audio signal 415 using a digital to analog converter 412.
It should be noted that herein the term "encoder" may refer to a complete encoder 400, the combined encoder 401 or encoder 404 frames. The term "decoder" may refer to a complete decoder 410, the combined decoder 411 or decoder 414 frames. On the other hand, so-called "Unreliable coders" are encoders, which do not generate an identifier or identifier is generated in accordance with the methods described herein.
FIG. 5 illustrates an exemplary broadcast system 500, which includes a head assembly 504 is broadcasting. The head assembly 504 also includes a device for concatenation or the concatenation means which operates to combine the bit streams 501, 502, 503 originating from different encoders. The broadcasting system characterized bitstreams 501, 502, 503 may be a bit audio streams are typically encoded by different audio encoders. Bitstreams 501, 502, 503 consist of a number of frames, which are represented by different shaded blocks. In the illustrated example, the bit stream 501 includes five frames, the bit stream 502 includes four frames, and the bit stream 503 includes six frames. An apparatus for concatenating and / or headend 504 acts to combine the bit streams in order to create a combined bit stream 505. As shown in the example, this combination may be accomplished by attaching the bit stream 501 to the bit stream 503, and by attaching the bit stream 502 to the bit stream 501 . However, as also shown in FIG. 5, may need to select only certain parts of the original bit streams 501, 502 and 503, for example, only a portion of bit audio streams. As such a combined bit stream 505 includes only two bit stream frame 503 following the two three bit stream frame 501 and the following two frames in the bitstream 502.
Original bitstreams 501, 502, 503 may include identifiers, i.e. bitstreams 501, 502, 503 may come from reliable encoders. Each of the identifiers may be based on different amounts of N frames. Without departing from the generality we can assume that the identifier bit streams 501 and 503 were determined for the group of frames consisting of two frames. On the other hand, the bitstream 502 is not derived from an encoder reliable and therefore does not include the identifier.
Desirably, the apparatus for concatenating and / or broadcast headend 504 bit stream 505, which would also include an identifier if the incoming bit streams 501 and 503 come from reliable encoder. This identifier must be sent in the bitstream 505 for all parts of the bit stream 505, which originate from a reliable encoder. On the other hand, parts of the bitstream 505, which do not originate from a trusted encoder, i.e. parts taken from the bit stream 502 need not include the identifier.
In order to achieve this purpose, the device can operate to concatenate performing decoding and / or encoding identifier. As shown in FIG. 5, the first two frames of the outgoing bit stream 505 are derived from the bitstream 503. If these two frames correspond to a group of frames, the identifier of the group of frames can be placed in the third frame bit stream 505. This arrangement is described in relation to FIG. 1. If, on the other hand, the two frames belonging to different groups of frames, the headend 504 may proceed to
• checking whether the bit stream 503 originating from a trusted encoder; and
• generating a new identifier for outgoing frames of the bit stream 503, ie, for the first two frames 505 bitstream.
The number N, is used for generating an identifier for the outgoing bit stream 505 need not be equal to the number N, used for generating an identifier for the outgoing bit streams 501 and 503. This can be considered in the context of the bitstream 501, for which only three frames in outgoing bit stream 505. The first identifier may be generated for the first two frames, while the second identifier may be generated for the third block. In other words, N may be equal to two for the first two frames, and N may be equal to one for a third frame. Therefore, in general, one can say that N can be varied within the bit stream 505. This is due to the fact that N may be determined in a decoder independently. Preferably, the number N, is used for the outgoing bit stream 505 is less than or equal to N, used for the incoming bit streams 501 and 503.
Furthermore, it should be noted that the incoming bit stream 502 does not include an identifier, i.e. bitstream 502 is not derived from a reliable encoder. Accordingly, the apparatus for concatenating and / or headend is not provided in the bitstream for the frame identifier 505, derived from the bit stream 502. As described above, the decoder is usually valid for detecting the absence identifier in the bit stream 505. If the number of frames not including the identifier exceeds a predetermined maximum number Nmax, the decoder typically will detect that the bit stream 505 is no longer coming from a reliable encoder.
As shown in the example of FIG. 5, bit stream 505 is composed of parts that come from a reliable encoder, and other parts that do not come from a reliable encoder. Accordingly, the bitstream 505 may include portions which include an identifier having a strength and other parts which do not include having the effect ID. An apparatus for concatenating and / or headend 504 may proceed to
• detect incoming bit stream, including the identifier;
• forwarding bitstream comprising identifier as an outgoing bit stream;
• authenticating the incoming bit stream based on the identifier; and
• bitstream by encoding the new identifier.
In other words, the apparatus for concatenating and / or headend 504 may include functions of the encoder and / or decoder described in this patent document. Those. apparatus for concatenating and / or headend 504 may function as a decoder upon receiving the incoming bit stream, and it can function as an encoder in generating the outgoing bitstream. In addition, it can act to redirect bitstream comprising identifier without performing an authentication and re-encoding. Operation redirection may be performed for the continuous transmission of the same bitstream while decoding and re-coding can preferably be used on the boundaries between the bit streams of different encoders. Using a redirection operation, it is possible to reduce the processing load on the apparatus for concatenating and / or headend 504.
It should be noted that the redirect operation can be used in cases where the preceding-frame identifier has no effect on the value of the identifier of the current GOP. In these cases, a group of staff and associated identifier can be regarded as an independent entity, which can be directly forwarded to the output bit stream. On the other hand, if the used continuous interconnected identifiers, wherein the identifier of the current-frame depends on the preceding-frame identifier, the device to concatenate, preferably, will be re-encode the entire bit stream to generate an outgoing bit stream flow continuously interconnected identifiers. This can ensure that an unauthorized party does not have the possibility of replacing an outgoing bitstream segments.
It should be noted that in most cases re-encoding apparatus for concatenating limited only generate new identifiers. By itself, the bit-stream, i.e., in particular bitstream audio coding, usually remains unaffected. Accordingly, re-encoding the bitstream can be performed with low computational complexity. However, if the cryptographic value is inserted into the frame, which was previously not contain cryptographic value may be necessary to perform a re-encoding the audio signal.
FIG. 6 also illustrates concatenation incoming bitstreams 1-4 concatenated outbound bit stream for the preferred embodiment. In the illustrated example, the incoming bit stream 1 forms a group of 4 frames to generate cryptographic values. Corner bitstream by arrows illustrate that the cryptographic value-frame is inserted in the first frame of the next group. The frames, which are inserted in the cryptographic values are shaded in FIG. GOP incoming bit stream 2 includes 6 frames, and a group of incoming bit stream frame 3 include 5 frames. The incoming bit stream 4 does not contain cryptographic values and is not a verified and trustworthy.
Vertical lines in the figure indicate the point of concatenation. As seen from the figure, the outgoing bitstream includes a first section I, the appropriate incoming bit stream 1, a second section II, the appropriate incoming bit stream 2, the third section III, the corresponding incoming bitstream 3, and a fourth section IV, the corresponding incoming bitstream 4 where sections are concatenated in the concatenation points. Before the first point of concatenation incoming bit stream 1 comprising cryptographic values can be copied into concatenated bit stream. However, the first cryptographic value in section II requires recomputation because of concatenation it relates to other data frames than the corresponding value of the cryptographic bit stream 2. In detail, the cryptographic value based on 5 frames: one belonging to the incoming bit stream 1 ( before the point of concatenation), and four - belonging to the incoming flow of 2 (after the point of concatenation). Re-calculation of the cryptographic values indicated by the arrows on the bit stream, and changes in shading. Due to changes in the propagation of the first cryptographic value recalculated on concatenated bitstream following cryptographic values bitstream 2 can also be computed repeatedly.
Contents4
13 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5 Sheet 6 Sheet 7 Sheet 8 Sheet 9 Sheet 10 Sheet 11 Sheet 12 Sheet 13
Every citation, both ways
| Document | Relation | Office | Cited during |
|---|---|---|---|
| EP1652383B1 | Cites | European Patent Office (EPO) | Search report |
| US2003182246A1 | Cites | United States of America | Search report |
| US2006136728A1 | Cites | United States of America | Search report |
| RU2308077C2 | Cites | Russian Federation | Search report |
| RU2351013C2 | Cites | Russian Federation | Search report |
| US20060136728A1 | Cites | United States of America | – |
| US20030182246A1 | Cites | United States of America | – |
32 members in 18 offices
Priority claims9
| Document | Office | Kind | Date |
|---|---|---|---|
| 23229509 | United States of America | P | |
| 23229509 | United States of America | P | |
| 61232295 | United States of America | – | |
| 2010004827 | European Patent Office (EPO) | W | |
| 2010004827 | European Patent Office (EPO) | W | |
| 61232295 | – | – | – |
| EP2010004827 | – | – | – |
| US20090232295P | – | – | – |
| WO2010EP04827 | – | – | – |
Members32
| Document | Office | Kind | |
|---|---|---|---|
| CA2768327A1 | Canada | A1 | |
| WO2011015369A1 | World Intellectual Property Organization (WIPO) | A1 | |
| AR077680A1 | Argentina | A1 | |
| TW201134135A | Taiwan Province of China | A | |
| AU2010280971A1 | Australia | A1 | |
| SG177605A1 | Singapore | A1 | |
| IL217469A0 | Israel | A0 | |
| IL217469D0 | Israel | D0 | |
| WO2011015369A8 | World Intellectual Property Organization (WIPO) | A8 | |
| MX2012001558A | Mexico | A | |
| KR20120050446A | Republic of Korea | A | |
| US2012128151A1 | United States of America | A1 | |
| EP2462587A1 | European Patent Office (EPO) | A1 | |
| CN102576559A | China | A | |
| HK1168461A | Hong Kong, China | A | |
| HK1168461A1 | Hong Kong, China | A1 | |
| JP2013500655A | Japan | A | |
| AU2010280971B2 | Australia | B2 | |
| RU2012107995A | Russian Federation | A | |
| UA104483C2 | Ukraine | C2 | |
| RU2509424C2This record | Russian Federation | C2 | |
| JP5542205B2 | Japan | B2 | |
| MY152679A | Malaysia | A | |
| US8885818B2 | United States of America | B2 | |
| KR101489364B1 | Republic of Korea | B1 | |
| IL217469A | Israel | A | |
| CN102576559B | China | B | |
| TWI501580B | Taiwan Province of China | B | |
| CA2768327C | Canada | C | |
| EP2462587B1 | European Patent Office (EPO) | B1 | |
| BR112012002831A2 | Brazil | A2 | |
| BR112012002831B1 | Brazil | B1 |
Numbers
- Publication
- 0002509424
- Publication, DOCDB
- 2509424
- Publication, EPODOC
- RU2509424
- Application
- 201210799508
- Application, DOCDB
- 2012107995
- Application, EPODOC
- RU20120107995
Titles2
- Russian
- АУТЕНТИФИКАЦИЯ ПОТОКОВ ДАННЫХ
- English
- DATA STREAM AUTHENTICATION
Classification
- CPC, 25
- G11B20/00086
- H04N21/2347
- G11B20/00007
- G11B20/00166
- G11B20/00173
- G11B20/00188
- G11B20/0021
- G11B2020/00028
- H04H20/31
- H04H60/37
- H04H60/73
- H04H2201/50
- H04N21/23424
- H04N21/235
- H04N21/2541
- H04N21/435
- H04N21/44016
- H04N21/462
- H04N21/6332
- H04N21/654
- H04N21/8106
- H04N21/835
- H04L65/762
- H04N7/24
- H04N21/8352
- IPC, 4
- H04L9 32
- H04N19 00
- H04N19 467
- H04N19 70