EP1645128A2 - Methode d'insertion de marques de synchronisation dans un flux video, compatible avec un chiffrage par blocs - Google Patents

Methode d'insertion de marques de synchronisation dans un flux video, compatible avec un chiffrage par blocs

Info

Publication number
EP1645128A2
EP1645128A2 EP04767623A EP04767623A EP1645128A2 EP 1645128 A2 EP1645128 A2 EP 1645128A2 EP 04767623 A EP04767623 A EP 04767623A EP 04767623 A EP04767623 A EP 04767623A EP 1645128 A2 EP1645128 A2 EP 1645128A2
Authority
EP
European Patent Office
Prior art keywords
data
bits
buffer
encrypted
bit
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP04767623A
Other languages
German (de)
English (en)
Inventor
Jean 9 allée Paul Cézanne NICOLAI
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
STMicroelectronics SA
Original Assignee
STMicroelectronics SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by STMicroelectronics SA filed Critical STMicroelectronics SA
Publication of EP1645128A2 publication Critical patent/EP1645128A2/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/16—Analogue secrecy systems; Analogue subscription systems
    • H04N7/167—Systems rendering the television signal unintelligible and subsequently intelligible
    • H04N7/1675—Providing digital key or authorisation information for generation or regeneration of the scrambling sequence
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/23614—Multiplexing of additional data and video streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H04N21/2389—Multiplex stream processing, e.g. multiplex stream encrypting
    • H04N21/23895—Multiplex stream processing, e.g. multiplex stream encrypting involving multiplex stream encryption
    • H04N21/23897—Multiplex stream processing, e.g. multiplex stream encrypting involving multiplex stream encryption by partially encrypting, e.g. encrypting only the ending portion of a movie
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H04N21/4348—Demultiplexing of additional data and video streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8455—Structuring of content, e.g. decomposing content into time segments involving pointers to the content, e.g. pointers to the I-frames of the video stream

Definitions

  • the present invention relates to a method for processing encrypted data, and to apparatuses and supports for its implementation.
  • the technical field of the invention is that of manufacturing video data coders.
  • the invention relates more particularly to a method of processing audio or video data partially encrypted by a block encryption algorithm, the data being compressed and organized according to a standardized format.
  • the secure distribution of video documents is today limited to the broadcasting of "pay" television by cable or satellite; security is ensured by "proprietary" encryption systems, which are defined, implemented and controlled by a single service provider: the broadcaster.
  • a- the syntax of the encrypted stream must remain as close as possible to the coding standard, in order to facilitate network transport; the data processing method must ensure transparency transcoding and speed changes, as well as transparency to routers and servers for reasons of trust; the method must allow random access and other video processing without decryption of the complete stream, and must allow transport by protocols intended for standard video; b- the compression efficiency must not be degraded due to the security of the data by encryption; c- the security must be compatible with various tools provided by the compression standards (MPEG4, H264) of video data, in particular error resistance, for wireless transmission and loss of IP packets (Internet protocol) as well as multi-level coding, for client terminals with heterogeneous bandwidth; d- the level of security and visual masking must be adapted to the application: robustness to attacks specific to video; e- the computing power required must remain compatible with on-board terminals, for applications such as wireless streaming of multimedia documents.
  • a video sequence consists of a series of groups of images, each group of images consisting of a series of type I (intrinsic), P (predicted) and B (bidirectional) images; each type I image is cut into macroblocks; each macroblock is converted into four luminance blocks and into two chrominance blocks, this conversion resulting in a first loss of information.
  • Each block of 64 pixels is converted into a table of 64 coefficients by a DCT transformation ("discrete cosine transform”); this table is compressed by quantization ("quanti zation”) then ordered and coded (“zig-zag ordering" and “run-length coding”) according to the number of zero value coefficients encountered during a zigzag scan of the table; the resulting compressed data is coded in words of variable length (“Huffman coding”); these transformations also lead to a loss of information.
  • DCT transformation discrete cosine transform
  • quantization quantization
  • zig-zag ordering zig-zag ordering
  • run-length coding coded in words of variable length
  • a fast MPEG video encryption algorithm describes a method of encrypting video data compressed in MPEG format, by a secret key; the sign bits of the Huffman coefficients (AC and DC) - which are variable length coded words - are bit-by-bit combined with XOR gates with a key of determined length, and are respectively replaced - in the video data stream - by the bit value resulting from this operation; in this document, it is proposed to use one or more long keys; a 128-bit key is used as an example.
  • synchronization points are added at the start of each group of images, at the start of each type I image or at the start of a predetermined number of images.
  • a periodic synchronization mark can be created at the end of a macroblock when the number of bits since the previous mark is greater than a certain threshold; a video packet (part of the flow between two successive marks) thus presents a variable number of macroblocks.
  • the number of data bits to be encrypted within such a video packet may be less than the number of bits of the encryption block, in particular when the packet contains the motion vectors associated with the P and B type images; in this case, such a packet will be transmitted without encryption, and the obfuscation of the sequence will be reduced.
  • the object of the present invention is to propose an improved method of inserting synchronization marks in a standardized stream of compressed and encrypted data.
  • the present invention also aims to provide such a method which overcomes - at least in part - the drawbacks of known methods of encryption of compressed audio and video data streams.
  • Another object of the invention is to provide an encoder or decoder (hardware and / or software) making it possible to implement the method according to the invention.
  • the invention proposes a method of inserting synchronization marks in a standardized stream of compressed and encrypted data, in which at least part of the stream of compressed data is encrypted bit by bit, by block encryption, and a synchronization mark is not inserted into the compressed data stream only after the number of encrypted bits has reached or exceeded the number of bits of the encryption block.
  • the invention proposes a method of inserting synchronization marks in a stream of compressed video data in MPEG and encrypted format, in which: - only part of the compressed data is encrypted bit by bit, with an algorithm block encryption of a predetermined number of bits s, - the bits to be encrypted of the compressed data stream are placed in a buffer whose size is equal to said predetermined number and a synchronization mark is inserted in the compressed data stream after the buffer has been filled.
  • the invention provides a medium readable by a computer on which is recorded a program code implementing the operations defined above, to allow the computer to broadcast a stream of compressed and encrypted data in accordance with the invention.
  • the invention proposes a compressed stream of encrypted data obtained indirectly by a method according to the invention.
  • the invention applies in particular to methods using a 64-bit, 128-bit, 192-bit, or 256-bit block encryption algorithm to encrypt one or more bit (s) - for example the sign bit - motion vector and / or texture image data of type I, P and ' B according to the MPEG4 standard.
  • the invention provides an encoder or decoder for formatted and compressed audio or video data, which comprises: - a buffer provided for temporarily receiving the selected data bits for encryption, - block encryption means suitable for encrypting the bits stored in the buffer, means for actuating the block encryption means, for causing the encryption of the bits stored in the buffer when the buffer is full, for replacing the bits selected in the data stream by the bits stored and encrypted, and to empty the buffer, the size of the buffer being equal to the number of bits of a block of the encryption means per block.
  • the size of the buffer is equal to an integer multiple of the number of bits of a block of the encryption means per block, which makes it possible to increase security by chaining several blocks.
  • FIG. 1 illustrates a part of a data stream to be processed according to the invention, which is in the form of a series of n macroblocks, each macroblock comprising motion vector data as well as texture data.
  • FIG. 2 schematically represents a system useful for implementing the invention.
  • FIG. 3 is a simplified flowchart of a procedure for inserting synchronization marks according to the invention.
  • FIG. 4 schematically illustrates the structure of part of the data flow obtained according to the invention from the flow illustrated in FIG. 1.
  • the proposed method consists in generating a synchronization mark if the number of bits since the last mark is above a certain threshold (see standard MPEG4 IS014496-2 appendix E), for example 2048 bits, and if the number of bits encrypted since the last mark is at least equal to the block size of the block encryption algorithm chosen, by example at least equal to 128 if the algorithm chosen is AES, or 64 if the algorithm chosen is DES.
  • a certain threshold see standard MPEG4 IS014496-2 appendix E
  • the number of bits encrypted since the last mark is at least equal to the block size of the block encryption algorithm chosen, by example at least equal to 128 if the algorithm chosen is AES, or 64 if the algorithm chosen is DES.
  • the elements of the header namely: the index of the first macroblock, the quantification factor, the HEC (header extension code), which are elements of syntax and not content.
  • the useful data consisting of motion vectors and of the texture, are not always encrypted in their entirety: for example, only the sign bits of the symbols are encrypted.
  • Example 1 after a synchronization mark, another synchronization mark is generated after the next macroblock as soon as the following 2 conditions are met: the total number of bits since the last synchronization mark is greater than 2048, and - the total number motion vector sign bits and texture DCT coefficients is greater than 128; this makes it possible to encrypt the first 128 sign bits in an AES block, the following bits being encrypted in blocks of 128, and the final bits less than 128 remaining in clear.
  • Example 2 (where the "video packet resynchronization" and “data partitioning” modes are used simultaneously): The "data partitioning" mode separates useful motion data (motion vectors) from useful texture data (DCT coefficients) by a mark of motion called "motion marker".
  • the proposed method consists in not introducing a new synchronization mark as long as the encrypted part of the motion vectors (full symbol or sign bits only) does not reach the quantity of 64 or 128 bits, or the block dimension of l 'encryption algorithm chosen, even if the maximum number of bits in "synchronization" mode has been reached.
  • Example 3 In this example corresponding to FIGS. 1 to 4, it is desired to encrypt only all or part of the data bits corresponding to the motion vectors.
  • the flow portion illustrated in FIG. 1 consists of an ordered temporal sequence of macroblocks MB1, MB2, ... MBi, ... MBn; each macroblock such as MBi includes motion vector data denoted MB M vi, and texture data denoted MB T ⁇ i; the movement data can be zero when the macroblock is coded without movement; the texture data can also be zero when the coefficients AC and DC are below the quantization threshold.
  • "Auto-synchronous" packets are packets that can be decrypted and decompressed without using data from other packets.
  • a data processing system 1 comprising three buffers marked T2 to T4; the buffers T2 and T3 each have a dimension of 2048 bits and are respectively provided for temporarily receiving the data MB MVi for T2, the data MB T ⁇ i for T3; the 128-bit T4 buffer is designed to receive the bits extracted from this data for encryption.
  • the processing of the macroblocks MBI, MB2, ... MBi, ... MBn is carried out in the following manner (see FIGS.
  • step 100a and 100b synchronization (200) and a header (210); - then, for the MBI macroblock and the following macroblocks: a) the movement data - such as MB MV i for the MBi macroblock - are concatenated in the buffer T2, b) extract (step 120) from these data the bits to be encrypted and concatenate these bits in the buffer T4, c) concatenate (step 130) the texture data - such as MB ⁇ xi for the macroblock MBi - in the buffer T3, d) it is checked (test 140) if the buffer T4 is full; in the negative (branch 150), the operations a) to d) are repeated for the following macroblock; e) in the affirmative, the bits selected and placed in T4 are encrypted, delivered one by one in the buffer T2 at the position they occupied before their encryption, and the buffer T4 is emptied (step
  • the data obtained ( Figure 4) thus comprise a series of self-synchronous packets, which are surrounded by two synchronization marks (200); alternatively, the texture data can be encrypted, preferably also selectively.
  • the texture data can be encrypted, preferably also selectively.
  • we insert a synchronization mark after an integer number of encrypted blocks by performing the test "x + y> N se u ⁇ i " only when we have completed the filling of a T4 encryption buffer.
  • a variant consists in carrying out this test at each macroblock, after at least one T4 buffer has been filled and encrypted; this will result in encrypting an integer number of blocks, leaving in the clear the final bits not reaching the threshold of

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

La présente invention est relative à une méthode d'insertion de marques (200) de synchronisation dans un flux standardisé de données compressées et chiffrées, dans laquelle on chiffre bit à bit une partie au moins du flux de données compressées, par chiffrement par bloc, et dans laquelle on n'insère une marque de synchronisation dans le flux de données compressées qu'après que le nombre de bits chiffrés ait atteint ou dépassé le nombre de bits du bloc de chiffrement.

Description

METHODE D'INSERTION DE MARQUES DE SYNCHRONISATION DANS UN FLUX VIDEO, COMPATIBLE AVEC UN CHIFFRAGE PAR BLOCS La présente invention est relative à une méthode de traitement de données chiffrées, et à des appareils et supports pour sa mise en œuvre. Le domaine technique de l'invention est celui de la fabrication de codeurs de données vidéo. L'invention est plus particulièrement relative à une méthode de traitement de données audio ou vidéo- partiellement chiffrées par un algorithme de chiffrement par bloc, les données étant compressées et organisées selon un format standardisé. La distribution sécurisée de documents vidéo est aujourd'hui limitée à la diffusion de télévision "à péage" par câble ou satellite ; la sécurité est assurée par des systèmes de chiffrement "propriétaires", qui sont définis, mis en œuvre et contrôlés par un prestataire unique : le diffuseur. Les nouveaux standards de vidéo à faible débit, l'Internet haute vitesse et les terminaux portables en réseau sans fil, de type téléphone 3G ou assistant personnel, devraient bientôt permettre la distribution de documents vidéo : télé-conférence, messages multimédias, bandes annonces de films, actualités sportives en direct, vidéo à la demande, notamment . Des besoins de sécurité apparaissent, qui ne peuvent être satisfaits par les solutions actuelles. Les contraintes sont les suivantes : a- la syntaxe du flux chiffré doit rester le plus conforme possible au standard de codage, afin de faciliter le transport en réseau ; la méthode de traitement de données doit assurer une transparence au transcodage et aux changements de débit, ainsi qu'une transparence aux routeurs et serveurs pour des raisons de confiance ; la méthode doit permettre l'accès aléatoire et d'autres traitements vidéo sans déchiffrage du flux complet, et doit permettre le transport par des protocoles prévus pour de la vidéo standard ; b- l'efficacité de compression ne doit pas être dégradée du fait de la sécurisation des données par chiffrage ; c- la sécurisation doit être compatible avec divers outils prévus par les standards de compression (MPEG4, H264) de données vidéo, en particulier la résistance aux erreurs, pour la transmission sans fil et les pertes de paquets IP (protocole Internet) ainsi que le codage multi niveaux, pour les terminaux clients à bande passante hétérogène ; d- le niveau de sécurité et de masquage visuel doit être adapté à l'application: robustesse aux attaques spécifiques à la vidéo ; e- la puissance de calcul requise doit rester compatible avec des terminaux embarqués, pour des applications telles que la transmission sans fil en flux continu de documents multimédia. Selon la norme MPEG, une séquence vidéo est constituée d'une suite de groupes d'images, chaque groupe d'image consistant en une suite d'images de type I (intrinsèque), P (prédite) et B (bidirectionnelle) ; chaque image de type I est découpée en macroblocs ; chaque macrobloc est converti en quatre blocs de luminance et en deux blocs de chrominance, cette conversion entraînant une première perte d'information. Chaque bloc de 64 pixels est converti en une table de 64 coefficients par une transformation DCT ("discrète cosine transform") ; cette table est compressée par quantification ( "quanti zation" ) puis ordonnée et codée ("zig-zag ordering" et "run-length coding") en fonction du nombre de coefficients de valeur nulle rencontrés lors d'un balayage en zigzag de la table; les données compressées résultantes sont codées en mots de longueur variable ("Huffman coding") ; ces transformations entraînent également une perte d'information. Diverses méthodes de chiffrement d'un flux de données vidéo standardisé - en particulier d'un flux au standard MPEG - ont été proposées en vue de satisfaire certaines des contraintes énoncées ci- avant . Le document "A fast MPEG video encryption algorithm", Changgui Shi et al, ACM Multimedia 98, décrit une méthode de chiffrement de données vidéo compressées au format MPEG, par une clé secrète ; les bits de signe des coefficients (AC et DC) de Huffman - qui sont des mots codés de longueur variable - sont combinés bit à bit à des portes XOR avec une clé de longueur déterminée, et sont respectivement remplacés - dans le flux de données vidéo - par la valeur de bit résultant de cette opération ; dans ce document, il est proposé d'utiliser une ou plusieurs clé (s) longues ; une clé de 128 bits est utilisée à titre d'exemple. Cette méthode de chiffrage sélectif, qui opère sur une faible partie du flux de données, nécessite des ressources de calcul moindres que celles nécessitées par les méthodes de chiffrage intégral du flux ; en contrepartie, l'obscurcissement des images chiffrées est relativement faible. Le brevet US- 6 , 505 , 299-Bl (Zeng et al) décrit des variantes de cette méthode, et propose de chiffrer les vecteurs de mouvement des images de type P et B ; ceci augmente l'obscurcissement des images chiffrées. Selon le document Changgui Shi et al, susmentionné, des points de synchronisation, qui sont ajoutés au flux de données, permettent à un décodeur disposant de la clé de savoir à partir de quelle position dans le flux chiffré, il doit recommencer à utiliser la clé de déchiffrage ; ces points de synchronisation sont ajoutés au début de chaque groupe d'images, au début de chaque image de type I ou au début d'un nombre prédéterminé d' images . Selon l'annexe E de la norme ISO 14496-2, dans un mode "video packet resynchroni zation" , une marque de synchronisation périodique peut être créée à la fin d'un macrobloc lorsque le nombre de bits depuis la marque précédente est supérieur à un certain seuil ; un paquet vidéo (partie du flux comprise entre deux marques successives) présente ainsi un nombre variable de macroblocs. Lorsque le flux de données est partiellement chiffré avec un algorithme de chiffrement par bloc, tel que les standards DES (bloc de 64 bits) et à fortiori AES (128 bits), le nombre de bits de données à chiffrer à l'intérieur d'un tel paquet vidéo, peut être inférieur au nombre de bits du bloc de chiffrage, notamment lorsque le paquet contient les vecteurs de mouvement associés aux images de type P et B; un tel paquet sera dans ce cas transmis sans chiffrement, et l'obscurcissement de la séquence sera diminué. La présente invention a pour objet de proposer une méthode améliorée d'insertion de marques de synchronisation dans un flux standardisé de données compressées et chiffrées. La présente invention a également pour objet de proposer une telle méthode qui remédie - en partie au moins - aux inconvénients des méthodes connues de chiffrage de flux de données audio et vidéo compressées . Un autre objet de l'invention est de proposer un codeur ou décodeur (matériel et/ou logiciel) permettant de mettre en œuvre la méthode selon 1 ' invention . Selon un premier aspect, l'invention propose une méthode d' insertion de marques de synchronisation dans un flux standardisé de données compressées et chiffrées, dans laquelle on chiffre bit à bit une partie au moins du flux de données compressées, par chiffrement par bloc, et on n'insère une marque de synchronisation dans le flux de données compressées qu'après que le nombre de bits chiffrés ait atteint ou dépassé le nombre de bits du bloc de chiffrement. Selon un autre aspect, l'invention propose une méthode d'insertion de marques de synchronisation dans un flux de données vidéo compressées au format MPEG et chiffrées, dans laquelle : - on chiffre bit à bit une partie seulement des données compressées, avec un algorithme de chiffrement par bloc d'un nombre prédéterminé de bit s , - on place les bits à chiffrer du flux de données compressées dans un tampon dont la dimension est égale audit nombre prédéterminé et on insère une marque de synchronisation dans le flux de données compressées après que le tampon ait été rempli. Selon un autre aspect, l'invention propose un support lisible par un, ordinateur sur lequel est enregistré un code de programme mettant en œuvre les opérations définies ci avant, pour permettre à l'ordinateur de diffuser un flux de données compressées et chiffrées conformément à l'invention. Selon un autre aspect, l'invention propose un flux compressé de données chiffrées obtenu indirectement par une méthode selon l'invention. L'invention s'applique en particulier aux méthodes utilisant un algorithme de chiffrement par bloc de 64 bits, de 128 bits, de 192 bits, ou de 256 bits pour chiffrer un ou plusieurs bit (s) - par exemple le bit de signe - des données de vecteurs de mouvement et/ou de texture d'images de type I, P et' B selon la norme MPEG4. Selon un autre aspect, l'invention propose un codeur ou décodeur de données audio ou vidéo formatées et compressées, qui comporte : - un tampon prévu pour recevoir temporairement les bits de données sélectionnés en vue de leur chiffrage, - des moyens de chiffrement par bloc aptes à chiffrer les bits stockés dans le tampon, des moyens pour actionner les moyens de chiffrement par bloc, pour provoquer le chiffrement des bits stockés dans le tampon lorsque le tampon est plein, pour remplacer les bits sélectionnés dans le flux de données par les bits stockés et chiffrés, et pour vider le tampon, la taille du tampon étant égale au nombre de bits d'un bloc des moyens de chiffrement par bloc. En variante, la taille du tampon est égale à un multiple entier du nombre de bits d'un bloc des moyens de chiffrement par bloc, ce qui permet d'augmenter la sécurité en chaînant plusieurs blocs. L'invention permet d'éviter qu'un paquet de données situé entre deux marques de synchronisation consécutives du flux de données ne soit transmis sans chiffrement. D'autres caractéristiques et avantages de l'invention apparaissent dans la description suivante, qui se réfère aux dessins annexés, et qui illustre sans aucun caractère limitatif, des modes préférés et exemples de réalisation de l'invention. La figure 1 illustre une partie d'un flux de données à traiter selon l'invention, qui se présente sous la forme d'une suite de n macroblocs, chaque macrobloc comportant des données de vecteurs de mouvement ainsi que des données de texture. La figure 2 représente schématiquement un système utile pour la mise en œuvre de l'invention. La figure 3 est un organigramme simplifié d'une procédure d'insertion de marques de synchronisation conforme à l'invention. La figure 4 illustre schématiquement la structure d'une partie du flux de données obtenu selon l'invention à partir du flux illustré figure 1. Selon un mode préféré de réalisation, la méthode proposée consiste à générer une marque de synchronisation si le nombre de bits depuis le dernier marque est supérieur à un certain seuil (cf. norme MPEG4 IS014496-2 annexe E), par exemple 2048 bits, et si le nombre de bits chiffrés depuis le dernier marque est au moins égal a la taille du bloc de l'algorithme de chiffrement par bloc choisi, par exemple au moins égal à 128 si l'algorithme choisi est l'AES, ou 64 si l'algorithme choisi est le DES. Ceci permet d'éviter que des paquets vidéo ne soient transmis en clair en raison de leur trop petite taille. Il est généralement nécessaire de vérifier les 2 conditions indépendamment car le nombre de bits chiffrés depuis la dernière marque n'est pas égal au nombre total de bits depuis la dernière marque ; en effet, le chiffrage est généralement sélectif et non normalisé. En général on ne chiffre pas les éléments de l'en tête, à savoir: l'index du premier macrobloc, le facteur de quantification, le HEC (header extension code), qui sont des éléments de syntaxe et non du contenu. De plus, les données utiles, constituées des vecteurs de mouvement et de la texture, ne sont pas toujours chiffrées dans leur totalité : par exemple, seuls les bits de signe des symboles sont chiffrés. Les symboles eux-mêmes étant de longueur variable, alors que le bit de signe est de longueur fixe, il n'y a pas une relation simple entre le nombre de bits total et le nombre de bits chiffrés . Exemple 1: après une marque de synchronisation, on génère une autre marque de synchronisation après le prochain macrobloc dès que les 2 conditions suivantes sont réunies : le nombre total de bits depuis la dernière marque de synchronisation est supérieur à 2048, et - le nombre total de bits de signes de vecteurs de mouvement et de coefficients DCT de texture est supérieur à 128 ; ceci permet de chiffrer les 128 premiers bits de signe en un bloc AES, les bits suivants étant chiffrés par blocs de 128, et les bits finaux en nombre inférieur à 128 restant en clair. Exemple 2 (où les modes "video packet resynchronization" et "data partitioning" sont utilisés simultanément) : Le mode "data partitioning" sépare les données utiles de mouvement (vecteurs de mouvement) des données utiles de texture (coefficients DCT) par une marque de mouvement appelé "motion marker" . Il est plus important de chiffrer les vecteurs de mouvement (par exemple leurs bits de signe), que les données de texture, car si l'on dispose des vecteurs de mouvement en clair il est possible de reconstituer l'image sans la texture. Or les vecteurs de mouvement sont codés en beaucoup moins de bits que la texture, et il est fréquent qu'ils représentent moins de 128 bits au total ; le risque existe donc de diffuser des paquets dont la partie "mouvement" est totalement en clair. La méthode proposée consiste à ne pas introduire de nouvelle marque de synchronisation tant que la partie chiffrée des vecteurs de mouvement (symbole complet ou bits de signe seulement) n'atteint pas la quantité de 64 ou 128 bits, ou la dimension de bloc de l'algorithme de chiffrage choisi, même si le nombre de bits maximal du mode "synchronisation" a été atteint. Exemple 3 : Dans cet exemple correspondant aux figures 1 à 4, on ne souhaite chiffrer que tout ou partie des bits de données correspondant aux vecteurs de mouvement . La portion de flux illustrée figure 1 consiste en une suite temporelle ordonnée de macroblocs MBl, MB2, ...MBi, ...MBn ; chaque macrobloc tel que MBi comporte des données de vecteurs de mouvement notées MBMvi, et des données de texture notées MBTχi ; les données de mouvement peuvent être nulles lorsque le macrobloc est codé sans mouvement ; les données de texture peuvent également être nulles lorsque les coefficients AC et DC sont inférieurs au seuil de quantification. On appelle paquets "auto-synchrones" des paquets pouvant être déchiffrés et décompressés sans l'aide de données provenant d'autres paquets. Pour créer des paquets "auto-synchrones" de longueur peu supérieure à un seuil N égal à 1024 bits et où les bits à chiffrer sont chiffrés avec l'algorithme de chiffrement par bloc AES, pour lequel la dimension des blocs de chiffrage est de 128 bits, on utilise (voir figure 2) un système 1 de traitement de données comportant trois tampons repérés T2 à T4 ; les tampons T2 et T3 ont chacun une dimension de 2048 bits et sont respectivement prévus pour recevoir temporairement les données MBMVi pour T2, les données MBTχi pour T3 ; le tampon T4 de 128 bits est prévu pour recevoir les bits extraits de ces données en vue de leur chiffrement. Le traitement des macroblocs MBI, MB2,...MBi, ...MBn est effectué de la façon suivante (voir figures 3 et 4 ) : avant traitement du 1er macrobloc MBI, on insère (étapes 100a et 100b) une marque de synchronisation (200) et un en-tête (210); - puis, pour le macrobloc MBI et les macroblocs suivants : a) on concatène (étape 110) les données de mouvement - telles que MBMVi pour le macrobloc MBi - dans le tampon T2, b) on extrait (étape 120) de ces données les bits à chiffrer et on concatène ces bits dans le tampon T4, c) on concatène (étape 130) les données de texture - telles que MBτxi pour le macrobloc MBi - dans le tampon T3, d) on vérifie (test 140) si le tampon T4 est plein ; dans la négative (branche 150), on répète les opérations a) à d) pour le macrobloc suivant ; e) dans l'affirmative, les bits sélectionnés et placés dans T4 sont chiffrés, remis un à un dans le tampon T2 à la position qu'ils occupaient avant leur chiffrage, et le tampon T4 est vidé (étape 160); f) on vérifie ensuite (test 170) si la somme du nombre total (x) de bits placés dans le tampon T2 et du nombre total (y) de bits placés dans le tampon T3 excède le seuil N ; dans la négative (branche 180), on répète les opérations a) à d) pour le macrobloc suivant ; g) dans l'affirmative, on place (étape 190) successivement à la suite de l'entête (210), les données de mouvement (220) sélectivement chiffrées contenues dans le tampon T2, une marque (230) de mouvement séparant les données de mouvement des données de texture, puis les données MBτxi de texture contenues dans le tampon T3; on vide les tampons T2 et T3, et on répète le cas échéant les opérations précédentes à partir de l'étape (100) . Les données obtenues (figure 4) comportent ainsi une série de paquets auto-synchrones, qui sont encadrés par deux marques de synchronisation (200) ; en variante, les données de texture peuvent être chiffrées, de préférence sélectivement également. On notera que, selon l'organigramme de la' figure 3, on insère une marque de synchronisation après un nombre entier de blocs chiffrés, en effectuant le test "x+y > Nseuιi" seulement quand on a fini le remplissage d'un tampon de chiffrement T4. Une variante consiste à effectuer ce test à chaque macrobloc, après qu'au moins un tampon T4 ait été rempli et chiffré ; cela aura pour résultat de chiffrer un nombre entier de blocs, en laissant en clair les bits finaux n'atteignant pas le seuil de

Claims

REVENDICATIONS
1. Méthode d'insertion de marques (200) de synchronisation dans un flux standardisé de données compressées et chiffrées, dans laquelle on chiffre bit à bit une partie au moins du flux de données compressées, par chiffrement par bloc, et dans laquelle on n'insère une marque de synchronisation dans le flux de données compressées qu'après que le nombre de bits chiffrés ait atteint ou dépassé le nombre de bits du bloc de chiffrement.
2. Méthode selon la revendication 1 dans laquelle les données sont des données vidéo au format MPEG, et dans laquelle: - on chiffre bit à bit une partie seulement des données compressées, avec un algorithme de chiffrement par bloc d'un nombre prédéterminé de bits , - on place les bits à chiffrer du flux de données compressées dans un tampon (T4) dont la dimension est égale audit nombre prédéterminé et on insère une marque (200) de synchronisation dans le flux de données compressées après que le tampon ait été rempli.
3. Méthode selon la revendication 1 ou 2 dans laquelle on compte le nombre total (x+y) de bits du flux de données écoulés depuis la précédente marque de synchronisation, et on n' insère une nouvelle marque de synchronisation qu'après que le nombre total de bits écoulés compté n'ait atteint ou dépassé un seuil (N) prédéterminé, ledit seuil étant supérieur audit nombre prédéterminé.
4. Méthode selon l'une quelconque des revendications 1 à 3 dans laquelle on utilise un algorithme de chiffrement par bloc de 64 bits, de 128 bits, de 192 bits, ou de 256 bits.
5. Méthode selon l'une quelconque des revendications 1 à 4, dans laquelle on chiffre plusieurs bit (s) des données (MBMVi) de vecteurs de mouvement d'images de type P et B.
6. Méthode selon l'une quelconque des revendications 1 à 4, dans laquelle on chiffre un seul bit - tel que le bit de signe - des données (MBMVÏ) de vecteurs de mouvement d'images de type P et B.
7. Méthode selon l'une quelconque des revendications 1 à 6, dans laquelle on chiffre plusieurs bit (s) des données (MBτxi) de texture d'images de type I, P et/ou B.
8. Méthode selon l'une quelconque des revendications 1 à 6, dans laquelle on chiffre un seul bit - tel que le bit de signe - des données (MBTXj.) de texture d'images de type I, P et/ou B.
9. Méthode selon l'une quelconque des revendications 2 à 8, dans laquelle : - avant traitement d'un 1er macrobloc (MBI) du flux de données, on insère (100) une marque de synchronisation (200) et un en-tête (210); puis, pour le 1er macrobloc (MBI) et les macroblocs suivants : a) on concatène (110) les données de mouvement dans un second tampon (T2) , b) on extrait (120) de ces données les bits à chiffrer et on concatène ces bits dans le tampon (T4) , c) on concatène (130) les données de texture dans un troisième tampon (T3), d) on vérifie (140) si le tampon (T4) est plein ; dans la négative (150), on répète les opérations a) à d) pour le macrobloc suivant ; e) dans l'affirmative, les bits sélectionnés et placés dans le tampon (T4) sont chiffrés, remis un à un dans le second tampon (T2) à la position qu'ils occupaient avant leur chiffrage, et le tampon (T4) est vidé (160); f) on vérifie ensuite (170) si la somme du nombre total (x) de bits placés dans le second tampon (T2) et du nombre total (y) de bits placés dans le troisième tampon (T3) excède un seuil (N) ; dans la négative (180), on répète les opérations a) à d) pour le macrobloc suivant ; g) dans l'affirmative, on place (190) successivement à la suite de l'entête (210), les données de mouvement (220) sélectivement chiffrées contenues dans le second tampon (T2), une marque (230) de mouvement séparant les données de mouvement des données de texture, puis les données (MBτxi) de texture ; on vide les tampons (T2) et (T3) , et on répète le cas échéant les opérations précédentes à partir de l'étape (100) .
10. Flux compressé de données chiffrées obtenu indirectement par l'une quelconque des revendications 1 à 9.
11. Codeur ou décodeur (1) de données audio ou vidéo formatées et compressées, caractérisé en ce qu'il comporte : un tampon (T4) prévu pour recevoir temporairement des bits de données sélectionnés en vue de leur ( dé ) chiffrage , - des moyens de ( dé ) chiffrement par bloc prévu pour (dé) chiffrer les bits stockés dans le tampon, - des moyens (110 à 160) pour actionner les moyens de ( dé ) chiffrement par bloc, pour provoquer le ( dé ) chiffrement des bits stockés dans le tampon lorsque le tampon est plein, pour remplacer les bits sélectionnés dans le flux de données par les bits stockés dans le tampon et (dé ) chiffrés , et pour vider le tam on, la taille du tampon (T4) étant égal au nombre de bits d'un bloc des moyens de ( dé ) chiffrement par bloc, ou bien égal à un multiple entier de ce nombre .
12. Support lisible par un ordinateur sur lequel est enregistré un code de programme mettant en œuvre les opérations définies à l'une des revendications 1 à 9, de façon à permettre à l'ordinateur de diffuser un flux de données compressées et chiffrées.
EP04767623A 2003-07-16 2004-07-08 Methode d'insertion de marques de synchronisation dans un flux video, compatible avec un chiffrage par blocs Withdrawn EP1645128A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0308639A FR2857813A1 (fr) 2003-07-16 2003-07-16 Methode d'insertion de marques de synchronisation dans un flux video, compatible avec un chiffrage par blocs
PCT/FR2004/001791 WO2005009047A2 (fr) 2003-07-16 2004-07-08 Methode d'insertion de marques de synchronisation dans un flux video, compatible avec un chiffrage par blocs

Publications (1)

Publication Number Publication Date
EP1645128A2 true EP1645128A2 (fr) 2006-04-12

Family

ID=33548153

Family Applications (1)

Application Number Title Priority Date Filing Date
EP04767623A Withdrawn EP1645128A2 (fr) 2003-07-16 2004-07-08 Methode d'insertion de marques de synchronisation dans un flux video, compatible avec un chiffrage par blocs

Country Status (4)

Country Link
US (1) US7787624B2 (fr)
EP (1) EP1645128A2 (fr)
FR (1) FR2857813A1 (fr)
WO (1) WO2005009047A2 (fr)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2124449A1 (fr) 2008-05-19 2009-11-25 THOMSON Licensing Dispositif et procédé de synchronisation d'une marque interactive vers un contenu de diffusion en continu
US20100278337A1 (en) * 2009-04-30 2010-11-04 Brandon Pliska Encryption-Based Location Masking
US9998750B2 (en) * 2013-03-15 2018-06-12 Cisco Technology, Inc. Systems and methods for guided conversion of video from a first to a second compression format

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5008935A (en) * 1989-06-30 1991-04-16 At&T Bell Laboratories Efficient method for encrypting superblocks of data
EP0619677A3 (fr) * 1993-04-09 1995-03-08 Matsushita Electric Ind Co Ltd Système pour embrouiller un signal vidéo numérique.
KR0152788B1 (ko) * 1994-11-26 1998-10-15 이헌조 디지탈 영상 시스템의 복사 방지 방법 및 장치
US6505299B1 (en) * 1999-03-01 2003-01-07 Sharp Laboratories Of America, Inc. Digital image scrambling for image coding systems

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2005009047A3 *

Also Published As

Publication number Publication date
FR2857813A1 (fr) 2005-01-21
WO2005009047A3 (fr) 2005-06-02
US20060182275A1 (en) 2006-08-17
US7787624B2 (en) 2010-08-31
WO2005009047A2 (fr) 2005-01-27

Similar Documents

Publication Publication Date Title
EP1645129B1 (fr) Methode de chiffrage d'un flux audio ou video compresse a tolerance d'erreurs
Liu et al. A survey of video encryption algorithms
EP1829379B1 (fr) Chiffrement d'une video h.264 preservant synchronisation et compatibilite de la syntaxe
US9350782B2 (en) Method and system for delivering media data
KR100942889B1 (ko) 데이터 부분을 최적화하는 방법
KR101002112B1 (ko) 데이터를 트랜스코딩하는 방법
KR101578055B1 (ko) 선택적 데이터 암호화를 위한 방법 및 장치
US10277656B2 (en) Method and system for delivering media data
EP1678586A1 (fr) Procede et dispositif pour garantir l'integrite de donnees
EP2491719B1 (fr) Procédé d'encapsulation de sous-flux de données, procédé de désencapsulation et programmes d'ordinateur correspondants
JP2013061650A (ja) データの暗号化を選択的にフォーマット維持する方法及び装置
KR100962852B1 (ko) 데이터를 프로세스하는 방법
US10848777B2 (en) Interleaved watermarking
EP1499061A1 (fr) Système et méthode de criptage video individuel
FR2874292A1 (fr) Procede de mise en forme de trames d'une sequence video
KR101041719B1 (ko) 데이터를 프로세싱하는 방법
US7505590B1 (en) Method and system for providing transcodability to frame coded streaming media
WO2005009047A2 (fr) Methode d'insertion de marques de synchronisation dans un flux video, compatible avec un chiffrage par blocs
EP1499126A1 (fr) Méthode de chiffrage d'un flux audio ou vidéo compressé préservant la syntaxe de codage
Janu et al. Development of an efficient real-time H. 264/AVC advanced video compression encryption scheme
JP2023007048A (ja) ストリーミングサーバ、送信方法及びプログラム
EP1499062B1 (fr) Système et méthode de criptage video individuel
WO2005018234A1 (fr) Procede et systeme de fourniture de donnees de media
FR2949283A1 (fr) Procede et installation pour marquer en temps reel un flux video compose d'une succession d'images video codees selon la norme mpeg-2.

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20051207

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): DE FR GB IT

DAX Request for extension of the european patent (deleted)
RBV Designated contracting states (corrected)

Designated state(s): DE FR GB IT

17Q First examination report despatched

Effective date: 20060523

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN WITHDRAWN

18W Application withdrawn

Effective date: 20080409