FR 2892879 A1 20070504 FR 0553277 A 20051027 Dispositif et procédé de transfert de données entre une source et un moyen de stockage. L'invention concerne un dispositif et un procédé de transfert de 5 données entre une source et un moyen de stockage. L'invention concerne plus particulièrement les transferts de données cryptées. L'implémentation de disques durs dans les décodeurs numériques 10 conduit à des problèmes de protection de contenu. En effet, les diffuseurs de contenu autorisent l'enregistrement de vidéos mais de manière limitée, en voulant contrôler le nombre de copies. La prolifération des moyens de stockage de type disque dur, DVD et autres peut conduire à une prolifération illégale des contenus. C'est pourquoi, de plus en plus, les vidéos doivent être 15 encryptées avant d'être enregistrées. L'invention a pour contexte le transfert de données cryptées sur un bus de données, entre une source et une destination pouvant être un moyen de stockage. L'encryptage des données et leur transfert sont coûteux en temps. Ce 20 transfert de données cryptées monopolise donc les bus de données pendant un temps trop long. Il est donc souhaitable de minimiser ce temps de transfert tout en cryptant les données pour garantir des temps de transfert les plus rapides possible. 25 A cet effet, l'invention propose un dispositif de transfert de données entre une source et au moins un moyen de stockage, les données devant être stockées de manière cryptée sur le moyen de stockage comprenant au moins deux moyens de transfert d'accès direct mémoire dont l'un est apte à crypter 30 les données au moment de leur transfert. Selon l'invention, afin de transférer les données de la source vers le moyen de stockage, les moyens de transfert d'accès direct mémoire transfèrent chacun alternativement des blocs de données, de manière à ce que les données enregistrées sur le moyen de stockage soient enregistrées en alternant des blocs de données cryptées et des blocs de données non cryptées. De cette manière, une seule partie des données est cryptée. Ceci suffit à rendre le cryptage suffisamment robuste pour que les données ainsi enregistrées ne puissent être lues par d'autres moyens de lecture et recopiées afin d'être lues et décryptées ultérieurement. Ainsi, le temps de transfert des données cryptées peut être réduit et le taux d'occupation du bus de transfert peut également être réduit. Selon un mode de réalisation préféré, la taille des blocs de données non cryptées est déterminée en fonction de la bande passante disponible entre la source et le moyen de stockage. De cette manière, il est éventuellement possible de crypter plus ou moins de données en fonction de la disponibilité des bus de transfert de données et donc d'augmenter ou de diminuer plus ou moins la taille relative des blocs de données cryptées et non cryptées. Avantageusement, les données étant codées sous la forme de groupes d'images, la taille des blocs de données n'est pas alignée sur ces groupes d'images. Ceci renforce la sécurité des données enregistrées et limite les risques de piratage puisque le non-alignement de la structure des données avec leur cryptage accentue nettement la difficulté de reconstitution des données. Selon un mode de réalisation préféré, les données étant codées sous la forme de groupes d'images, la taille des blocs de données est alignée sur ces groupes d'images. Selon un mode de réalisation préféré, la taille des blocs de données cryptées et non cryptées est inférieure à la taille d'une image. Avantageusement, des informations relatives à la taille des blocs sont enregistrées dans les moyens de stockage.30 Selon un mode de réalisation particulier, les données d'un groupe d'images étant codées de façon dépendante telle que le codage d'une première image est utilisé pour coder au moins une autre image, seules les images dont le codage est indépendant des autres images sont transférées par les moyens de transfert direct aptes à crypter les données, les autres images étant transférées par les moyens de transfert non aptes à crypter les données. Avantageusement, la taille des blocs est alignée sur la taille des blocs utilisés pour le cryptage des données par les moyens de transfert d'accès direct mémoire aptes à crypter les données. De manière préférée, les données comprenant un motif récurrent, la taille des blocs de données cryptées et non cryptées est multiple dudit motif. Cela permet avantageusement de ne pas enregistrer d'informations relatives à la taille des blocs dans les moyens de stockage car la taille des blocs est facilement détectable en recherchant le motif dans les données enregistrées. De cette manière, on peut aisément retrouver les blocs de données cryptées et non cryptées dans les données enregistrées en s'alignant sur le motif. Selon un autre aspect, l'invention concerne également un procédé de transfert de données entre une source et au moins un moyen de stockage, les données devant être stockées de manière cryptée sur le moyen de stockage comprenant une étape de transfert d'accès direct mémoire et de cryptage simultané des données au moment de leur transfert et une étape de transfert d'accès direct mémoire sans cryptage simultané des données. Selon l'invention, afin de transférer les données de la source vers le moyen de stockage, les étapes de transfert d'accès direct mémoire avec cryptage simultané et sans cryptage simultanés sont alternées, de manière à ce que les données enregistrées sur le moyen de stockage soient enregistrées en alternant des blocs de données cryptées et des blocs de données non cryptées. L'invention sera mieux comprise et illustrée au moyen d'exemples de modes de réalisation et de mise en oeuvre avantageux, nullement limitatifs, en référence aux figures annexées sur lesquelles : - la figure 1 représente un dispositif selon un mode de réalisation préféré de l'invention, - la figure 2 représente un exemple de transfert de données, - la figure 3 représente un mode de réalisation préféré de l'invention. Dans la description qui suit, les modules représentés sont des unités fonctionnelles, qui peuvent ou non correspondre à des unités physiquement distinguables. Par exemple, ces modules ou certains d'entre eux peuvent être regroupés dans un unique composant, ou constituer des fonctionnalités d'un même logiciel. A contrario, certains modules peuvent être éventuellement composés d'entités physiques séparées. Le mode préféré de réalisation illustré ci-dessous se base sur un flux conforme à la norme H264 ou MPEG-2 mais l'invention ne se limite pas à ces normes et peut s'appliquer à d'autres types de données. La figure 1 représente un dispositif selon un mode de réalisation préféré de l'invention. Un module front-end 1 est relié à un réseau externe qui peut-être de type câble, satellite, terrestre, IP. Ce module démodule notamment les signaux reçus et transmet un flux de données numériques à un module 9 de traitement de données. Le module 9 reçoit les données venant du front-end 1. Ce module traite les données reçues afin de les décoder, pour les afficher sur un téléviseur 16 ou pour les enregistrer sur un disque dur interne 8 ou sur un disque dur externe 12. Le module 9 est typiquement connu comme un décodeur numérique de télévision. Ce décodeur est équipé de différentes fonctionnalités telles que l'enregistrement de données audio vidéo, la possibilité de rejouer des données audio vidéo selon différents modes spéciaux, avance arrière, avance rapide, lecture en différée des données reçues tout en maintenant l'enregistrement simultané. Ces différentes fonctionnalités engendrent des transferts de données importants sur les différents bus de donnés entre le disque dur 8 et le processeur 2, entre une mémoire RAM 6 et le disque dur 8 et vers une interface USB hôte 3. L'occupation importante de ces bus de données peut parfois ralentir les modes de lecture spéciaux (avance rapide ou retour rapide...) qui demandent beaucoup de bande passante. D'autre part, afin de se créer une bibliothèque personnelle de vidéos par exemple, un module de stockage externe 10 est relié au décodeur par l'intermédiaire d'une connexion de type USB. L'interface USB hôte 3 du décodeur est reliée par un câble 11 à l'interface USB 13 du module de stockage 10. Ce module de stockage 10 comprend également un micro contrôleur 14 et le moyen de stockage 12 représenté par un disque dur. Ce module de stockage 10 est destiné à enregistrer les données audio vidéo reçues par le module 9 et que l'utilisateur souhaite conserver. Bien entendu, le disque dur interne 8 est également apte à enregistrer des données audio vidéo mais sa capacité est limitée et il est donc avantageux de bénéficier d'une unité de stockage externe et modulable si possible, de manière à augmenter les capacités de stockage. Le module de stockage externe 10 peut également être du type clé USB. Pour des raisons de protection de contenu et de préservation des droits d'auteur, les données doivent être enregistrées sur le disque dur de manière cryptée afin qu'elles ne puissent être piratées. Les données reçues sont parfois reçues déjà cryptées selon le cryptage utilisé par le protocole DVB. Le cryptage des données est effectué par un module de cryptage 4 qui remplit également une fonction de transfert de données de type DMA (acronyme anglais de direct memory access ) qui permet des transferts de données rapide entre une mémoire et un périphérique ou entre deux mémoires. Le module de cryptage 4 est un module intégré au processeur hôte 2. Celui-ci comprend également un DMA 5 qui ne réalise pas la fonction d'encryptage. Les différents types d'applications effectuées par le décodeur sont : -l'enregistrement de données sur le disque dur externe 12 (ou interne 8), -la relecture de données sur le disque dur externe 12 (ou interne 8), - la lecture et l'enregistrement simultanés de données sur le disque dur externe 12 (ou interne 8), - la lecture en différée d'un programme en cours d'enregistrement (timeshift en anglais) et l'enregistrement d'un autre programme sur l'autre disque dur, - l'archivage des données sur le disque externe 12. L'archivage des données sur le disque dur externe 12, par exemple préalablement enregistrées sur le disque dur interne 8, prend du temps et peut être considéré comme une tâche de fond qui doit être rendue transparente pour l'utilisateur. Cette tâche doit donc être réalisée dans un temps le plus court possible, pour éviter une occupation trop longue des bus de données et ainsi pénaliser les autres temps de transfert. L'invention est donc particulièrement avantageuse lors de cette application d'archivage mais n'est pas limitée à cette fonction. Le DMA 4 qui assure la fonction d'encryptage a des performances nettement inférieures au DMA simple 5 en terme de temps de transfert des données. Le processeur hôte 2, afin d'augmenter la bande passante dans le décodeur va donc programmer les deux DMAs 4 et 5 de manière à ce que les données à encrypter et à transférer soient partiellement encryptées. Les données écrites dans le disque dur destinataire 8 ou 12 ne sont donc pas toutes encryptées mais elles sont encryptées par blocs. Ainsi, les deux DMAs sont programmés pour transférer chacun des blocs d'une taille prédéterminée. Cette taille dépend essentiellement de la bande passante disponible dans le décodeur. Elle peut aussi dépendre des autres applications en cours au moment du transfert/encryptage. L'application ou les caractéristiques du décodeur requièrent bien souvent des débits prédéterminés pour obtenir des temps de transfert également prédéterminés. Ainsi, lorsque le débit requit pour transférer des données entre le disque dur interne 8 et le disque dur externe 12 est de 200Mbit/s, on peut calculer facilement la part de transfert effectuée par le DMA 4 et la part de transfert faite par le DMA 5 selon les équations suivantes : aVDMA4+ RVDMA5 a+R Avec V le débit total sur le bus, VDMA4 le débit maximal du DMA 4 et 10 VDMA5 le débit maximal du DMA5. a et R sont des coefficients de pondération de chacun des débits pour parvenir au débit V. Lorsque l'application requiert un débit Vobj, inférieur au débit V, on obtient alors : 15 VobJ ' Soit dans l'exemple de réalisation, en ayant 20 Vobj= 200Mbit/s VDMA4=150Mbit/s VDMA5=300Mbit/s On obtient alors: On choisit a + R = 20K, en fonction de la bande passante disponible et des différentes applications concurrentes. Ainsi, on obtient 30 a=6.666 V= 25 (3=13.333 Ainsi, le DMA 5 est programmé pour transférer des blocs de 7 Koctets et le DMA 4 est programmé pour transférer des blocs de 13 Koctets. Ainsi, les données présentes dans le disque dur 12 sont composées alternativement de blocs de 7 koctets de données cryptées et de blocs de données de 13 Koctets non cryptés. Ce taux de cryptage est suffisant pour que la personne qui souhaite visualiser la vidéo archivée ne puisse pas voir correctement et cela évite donc le piratage. Lors de la relecture des données dans le disque dur, les données doivent être identifiables comme des données cryptées ou non cryptées. A cet effet, des méta-données sont enregistrées sur le disque dur 12 avec les données utiles au cours de l'enregistrement ou en début d'enregistrement. Ces méta-données permettent d'identifier les secteurs dans lesquels les données sont cryptées et sont représentées par exemple par une simple indication de la taille des blocs, soient 7k et 13k. Dans d'autres modes de réalisation la taille relative des blocs cryptés 20 et non cryptés peut prendre d'autres valeurs. L'utilisation de DMAs permet de transférer des données rapidement sur le bus. Pour que l'utilisation du DMA soit efficace, il est important que les blocs de données à transférer soient de taille assez importante pour que le temps de reprogrammation des deux DMAs entre chaque transfert reste 25 négligeable par rapport à la durée d'un transfert de bloc de données. Le transfert alternatif d'un octet crypté puis d'un octet non crypté assurerait une très bonne sécurité au niveau cryptage mais prendrait trop de temps et ne résoudrait pas le problème de temps de transfert sur le bus. Il est nécessaire donc de faire un compromis entre la taille des blocs de données et 30 la sécurité de cryptage souhaitée. D'autre part, certains DMA encrypteurs ont également des exigences et nécessite parfois de crypter plusieurs octets simultanément. 8 La figure 2 représente un exemple d'organisation des données lors d'un transfert tel que décrit en figure 1. La figure 2 concerne le transfert de données entre le disque dur interne 8 et le disque dur externe 12. Les données sont au préalable enregistrées sur le disque dur interne 8 et lorsque l'utilisateur souhaite les transférer sur son disque dur externe 12, pour de la sauvegarde à long terme, les données sont encryptées avant d'être sauvegardées. Les données reçues sur le module de traitement 9 sont des données 10 encodées au format MPEG-2 ou MPEG-4 et structurées sous la forme de GOPs (acronyme anglais de group of pictures ). La taille d'un GOP est variable en fonction de la complexité des données images, en fonction du mouvement...Par exemple, dans le cas d'un débit de 4Mbits/s, la taille d'un GOP peut-être de 256Koctets. 15 Les données sont transférées dans le disque dur externe 12 par blocs de 7 koctets cryptés et de 13 koctets non cryptés. Le GOP 1, dont la taille est supérieure à 8Koctets est donc transféré partiellement de manière crypté et partiellement de manière non crypté. Ainsi 20 la taille d'un GOP ne correspond pas à la taille d'un transfert DMA. Ceci renforce encore la notion de sécurité et complexifie le piratage des données. Dans un autre mode de réalisation non représenté, non seulement un GOP n'est pas transféré de manière totalement cryptée ou totalement non 25 cryptée mais une image elle-même est transférée de manière fragmentée, certaines parties étant cryptées d'autres ne l'étant pas. La taille des blocs transférés est alors inférieure à la taille d'une image codée. Ainsi, les images sont toutes transférées, une partie cryptée alternant avec une partie non cryptée et ainsi de suite selon la taille de l'image et des blocs transférés. Ceci 30 est notamment le cas lorsque l'on a un débit de 256 KOctets et que la taille d'une image I fait deux fois la taille d'une image P et que la taille d'une image P fait deux fois la taille d'une image B. Lorsque le GOP comprend 12 images comme indiqué en figure 3, on a l'équation suivante : 256KO = I +3P+8B = 4B+6B+8B =18B On obtient donc les tailles d'images suivantes : B =14KOctets P = 28KOctets I = 56KOctets Dans ce cas, lorsque les blocs de données cryptées sont de taille 13KOctets et les blocs de données non cryptées sont de taille 7KOctets, les images I, P et B sont toutes transférées et enregistrées partiellement cryptées et non cryptées car la taille des blocs n'est donc pas alignée sur la taille des images. Ce qui rend leur visualisation claire impossible. Dans d'autres modes de réalisation, pour aligner la taille des GOPs sur la taille des images, il est par exemple envisageable de prendre une taille de bloc multiple de 14 KOctets mais dans ce cas, certaines images sont totalement non cryptées. Par contre, elles sont codées selon la norme MPEG-2 et dans ce cas doivent être décodées avant d'être visualisées. Elles n'apparaissent donc pas en clair même si elles ne sont pas cryptées car leur décodage dépend d'images cryptées. La figure 3 représente un GOP codé selon la norme H264. Cet exemple illustre le mode de réalisation particulier dans lequel seules les images I (images intra) sont cryptées et transférées par le DMA 4. Cet exemple de réalisation particulier nécessite de connaître l'emplacement des images I dans le flux de données à transférer et à crypter. De plus, la taille des images I n'étant pas constante, elle dépend de la complexité de codage de l'image, la taille des blocs à transférer varie alors d'un GOP à l'autre ce qui rend moins facile la programmation des deux DMAs 4 et 5. Il faut en effet connaître la taille des différentes images pour pouvoir programmer le DMA, ce qui peut être coûteux en temps. Dans un autre mode de réalisation non représenté, on transfère les GOPs de manière alternative par le DMA 4 et le DMA 5. Ce mode de réalisation nécessite également de connaître la taille de chaque GOP pour paramétrer les transferts DMA. Afin de relire les données qui ont été transférées comme décrit précédemment, il est nécessaire de pouvoir retrouver dans le moyen de stockage quels sont les blocs cryptés et quels sont les blocs non cryptés. Ainsi, des métadonnées sont enregistrées sur le moyen de stockage avec les données stockées auxquelles elles sont associées. A chaque fichier ainsi enregistré sur le disque dur 12, un fichier de métadonnée est associé. Ce fichier comprend la taille des blocs utilisée pour transférer les données. Il comprend donc une taille de blocs pour les données cryptées et une taille de blocs pour les données non cryptées. Lors de la relecture des données dans le module de stockage 10, le fichier de méta données correspondant au fichier de données à lire est lu avant de lire les méta données. Dans un autre mode de réalisation, il est également possible de ne pas stocker la taille des blocs dans le disque dur externe mais de stocker un code représentatif de la taille de bloc, ce qui renforce la sécurisation des données. Ce code est déterminé par le processeur hôte 2 qui associe à chaque taille de bloc un code particulier qu'il peut décoder lors de la relecture du fichier de méta données dans le disque dur 12. Lorsque les données sont enregistrées en utilisant le format TS (acronyme anglais de transport stream ), format de paquet selon la norme MPEG-2, alors les données comprennent tous les 188 octets un octet dont la valeur est 47 en hexa Les données comportent donc un motif récurrent comprenant un octet à la valeur 47 et 187 octets suivants. Il est donc également possible de s'aligner sur cet octet et de le retrouver dans le flux de données enregistré. Pour cela, la taille des blocs de données cryptées et non cryptées doit être multiple de 188 octets. Ainsi, lors de la relecture on recherche les octets de valeur 47 . Lorsque l'on ne rencontre plus un octet de valeur 47 188 octets après avoir rencontré le précédent, on détecte que les 188 octets qui vont suivre sont des données cryptées et ainsi de suite. Dans un autre mode de réalisation, la taille des blocs de données varie régulièrement, ceci pour complexifier la structure des données enregistrées en mémoire et donc pour complexifier leur piratage. On transfère par exemple une série de blocs de données de taille 7 koctets cryptées et 13 Koctets non cryptées puis ensuite on transfère une série de blocs de 5 Koctets cryptés et 15 Koctets non cryptés. Revendications 1. Dispositif de transfert de données entre une source (15) et au moins un moyen de stockage (8, 12), les données devant être stockées de manière cryptée sur ledit moyen de stockage (8,12), comprenant au moins deux moyens (4, 5) de transfert d'accès direct mémoire dont l'un est apte à crypter les données au moment de leur transfert, caractérisé en ce que, afin de transférer les données de ladite source vers ledit moyen de stockage (8,12), les moyens de transfert d'accès direct mémoire (4,5) transfèrent chacun alternativement des blocs de données, de manière à ce que les données enregistrées sur ledit moyen de stockage (8,12) soient enregistrées en alternant des blocs de données cryptées et des blocs de données non cryptées. 2. Dispositif selon la revendication 1 caractérisé en ce que la taille des blocs de données non cryptées est déterminée en fonction de la bande passante disponible entre la source (15) et le moyen de stockage (8,12). 3. Dispositif selon la revendication 1 caractérisé en ce que les données étant codées sous la forme de groupes d'images (GOP), la taille des blocs de données n'est pas alignée sur ces groupes d'images (GOP). 25 4. Dispositif selon la revendication 1 caractérisé en ce que les données étant codées sous la forme de groupes d'images (GOP), la taille des blocs de données est alignée sur ces groupes d'images (GOP). 5. Dispositif selon la revendication 1 caractérisé en ce que la taille des 30 blocs de données cryptées et non cryptées est inférieure à la taille d'une image.20 6. Dispositif selon l'une des revendications 1 à 3 caractérisé en ce que des informations relatives à la taille des blocs sont enregistrées dans les moyens de stockage (8,12). 7. Dispositif selon la revendication 1 caractérisé en ce que les données d'un groupe d'images (GOP) étant codées de façon dépendante telle que le codage d'une première image est utilisé pour coder au moins une autre image, seules les images (I) dont le codage est indépendant des autres images sont transférées par les moyens (4) de transfert direct aptes à crypter les données, les autres images étant transférées par les moyens (5) de transfert non aptes à crypter les données. 8. Dispositif selon la revendication 1 caractérisé en ce que les informations relatives à la taille des blocs sont enregistrées de manière codée dans lesdits moyens de stockage (8,12). 9. Dispositif selon la revendication 1 caractérisé en ce que, les données comprenant un motif récurrent, la taille des blocs de données cryptées et non cryptées est multiple dudit motif. 10. Procédé de transfert de données entre une source (15) et au moins un moyen de stockage (8,12), les données devant être stockées de manière cryptée sur ledit moyen de stockage (8,12), comprenant une étape de transfert d'accès direct mémoire et de cryptage simultané des données au moment de leur transfert et une étape de transfert d'accès direct mémoire sans cryptage simultané des données, caractérisé en ce que, afin de transférer les données de ladite source (15) vers ledit moyen de stockage (8,12), les étapes de transfert d'accès direct mémoire avec cryptage simultané et sans cryptage simultanés sont alternées, de manière à ce que les données enregistrées sur ledit moyen de stockage (8, 12) soient enregistrées en alternant des blocs de données cryptées et des blocs de données non cryptées.