FR2895612A1

FR2895612A1 - Procede de restitution protegee d'un flux numerique par un fichier executable multi plate formes

Info

Publication number: FR2895612A1
Application number: FR0513389A
Authority: FR
Inventors: Christian Brugeron
Original assignee: Individual
Current assignee: Individual
Priority date: 2005-12-23
Filing date: 2005-12-23
Publication date: 2007-06-29

Abstract

L'invention concerne un procédé de restitution d'un flux numérique sur une machine d'un utilisateur, caractérisé en ce qu'il comprend au moins les étapes consistant à :- générer un fichier exécutable comprenant ledit flux numérique crypté, ledit cryptage étant unique pour ledit flux numérique, un moyen de décryptage dudit cryptage unique, un moyen de lecture dudit flux numérique dans son format et au moins un identifiant de la machine sur laquelle ledit flux numérique est destiné à être joué.- Exécuter ledit fichier exécutable pour la restitution dudit flux numérique en cas de comparaison positive entre l'identifiant de la machine sur laquelle ledit flux numérique est destiné à être joué et ladite machine de l'utilisateur.

Description

1 PROCEDE DE RESTITUTION PROTEGEE D'UN FLUX NUMERIQUE PAR UN FICHIER

EXECUTABLE MULTI-PLATEFORMES ET VARIATIONS ALEATOIRES La présente invention se rapporte au domaine de la gestion des droits numériques.

La présente invention se rapporte plus particulièrement au domaine de la gestion des droits numériques, par exemple pour gérer les droits des musiques qui sont téléchargées à partir d'un réseau distant.

Les spécialistes de la gestion des droits numériques cherchent depuis plusieurs années à protéger efficacement le contenu musical pour le respect des droits de propriété intellectuelle.

À l'heure actuelle, on se rend compte que les solutions de protection des CD ne sont pas satisfaisantes, et surtout que la gestion des MP3 sur Internet pose un problème de fond aux autorités.

Pour remédier à ce problème, la solution largement adoptée par les fabricants de lecteurs est de protéger le lecteur (Player par exemple de type iTunes ou Windows Media Player) associé à un fichier musical contenant les droits. Selon ces solutions, on affecte au lecteur une très grosse clé, et les fichiers musicaux téléchargés contiennent cette clé et ne peuvent donc être lus qu'avec un lecteur adéquat.

L'art antérieur connaît également, par la demande US 2002/0161996 (Koved et al.) une solution de 2 protection dans les couches de programme du système d'exploitation ou de l'interpréteur JAVA d'une machine.

Presque toutes ces solutions sont basées sur la sécurisation du player uniquement. Dans ce cas, une fois la clé du player découverte, il est possible de lire tout type de fichier à l'aide d'un simple programme qui produit cette clé à la place du player.

On comprend bien que les solutions consistant à protéger des couches de la machine se heurte au même écueil.

La présente invention entend remédier aux inconvénients de l'art antérieur en ne mettant plus en oeuvre un lecteur unique protégé par une clé, mais un exécutable autonome protégé directement associé aux morceaux musicaux.

Pour ce faire, la présente invention est du type décrit ci-dessus et elle est remarquable, dans son acception la plus large, en ce qu'elle concerne un procédé de restitution d'un flux numérique sur une machine d'un utilisateur, caractérisé en ce qu'il comprend au moins les étapes consistant à : - Générer un fichier exécutable comprenant ledit flux numérique crypté, ledit cryptage étant unique pour ledit flux numérique, un moyen de décryptage dudit cryptage unique, un moyen de lecture dudit flux numérique dans son format et au moins un identifiant de la machine sur laquelle ledit flux numérique est destiné à être joué. - Exécuter ledit fichier exécutable pour la restitution dudit flux numérique en cas de comparaison 3 positive entre l'identifiant de la machine sur laquelle ledit flux numérique est destiné à être joué et ladite machine de l'utilisateur.

De préférence, il comprend en outre une étape préalable d'identification de la machine sur laquelle ledit flux numérique est destiné à être joué.

L'invention concerne également un fichier de restitution d'un flux numérique destiné à être joué sur une machine d'un utilisateur caractérisé en ce que ledit fichier est un fichier exécutable comprenant ledit flux numérique crypté, ledit cryptage étant unique pour ledit flux numérique, un moyen de décryptage dudit cryptage unique, un moyen de lecture dudit flux numérique dans son format et au moins un identifiant de la machine sur laquelle ledit flux numérique est destiné à être joué.

De préférence, ledit cryptage est réalisé par une clé de cryptage.

Avantageusement, ledit cryptage est réalisé par un procédé de cryptage.

Selon un mode de réalisation, ladite clé de cryptage est générée aléatoirement.

Selon une variante, ladite clé de cryptage correspond à une partie du fichier exécutable lui-même. De la même façon, ledit procédé de cryptage peut être choisi de façon aléatoire parmi un ensemble de procédés prédéterminé.30 De même, ledit format du flux numérique peut être choisi de façon aléatoire parmi un ensemble de formats prédéterminé On comprendra mieux l'invention à l'aide de la description, faite ci-après à titre purement explicatif, d'un mode de réalisation de l'invention, en référence aux figures annexées : la figure 1 illustre une étape de l'invention correspondant à un enregistrement de fichiers musicaux et de fichiers clients dans un serveur de stockage; la figure 2 illustre la création de fichiers musicaux cryptés au niveaux d'un serveur de livraison ; la figure 3 illustre le format d'un fichier exécutable selon l'invention; - la figure 4 illustre les différentes étapes de la lecture du fichier exécutable au niveau du poste client ;

Lors d'une étape préalable d'inscription, un client télécharge un logiciel d'inscription. Ce kit d'inscription installé sur une machine permet de prendre une signature du poste client. Cette signature contient plusieurs paramètres de la machine client comme par exemple l'adresse MAC, le numéro de série du disque dur, ou du processeur, ou le vendeur du disque dur ou du processeur. Cette signature peut comprendre tout ou partie de ces paramètres et être par exemple cryptés par une clé légère. Lorsque l'utilisateur s'inscrit sur le service correspondant à la présente invention, par exemple via Internet ou par email, cette signature est transmise à un serveur de stockage (1), comme illustré figure 1. De manière connue, l'utilisateur reçoit en retour un identifiant de type Login/Mot de passe afin de s'identifier au service lors des achats de musique. La 5 signature du poste client est donc stockée dans ce serveur sous la forme d'un fichier de client. Elle correspond à un identifiant de la machine sur laquelle les différents fichiers numériques seront destinés (et autorisés) à être lus. Il est entendu que le serveur de stockage (1) contenant l'ensemble des fichiers des clients sous la forme de paramètres des machines, ce serveur doit être sécurisé au maximum. Tout procédé de sécurisation connu de l'homme du métier est ici utilisable sans limitation sur la portée de la présente invention.

Le serveur de stockage comprend également les fichiers musicaux fournis par un ayant droit musical. Pour cela, l'ayant droit met à disposition du service selon la présente invention, ses fichiers musicaux. Ces fichiers sont stockés au niveau du serveur de stockage, par exemple dans un format haute définition le plus proche de la matrice sonore de l'ayant droit.

Illustré figure 2, lorsqu'un client désire télécharger une musique depuis un poste client, il s'identifie au niveau du serveur grâce à son login/mot de passe, et choisi une musique à télécharger. Lorsque la musique est choisie, celle-ci est alors envoyée vers un serveur de livraison 3, via un serveur 2 de génération de clé, de format, et de procédé de cryptage. Le premier choix à réaliser est celui du format musical du fichier dans lequel sera inséré ultérieurement le fichier numérique au sein d'un fichier exécutable. Ce format peut être par exemple de type MP3, OGG-VORBIS, ou tout format 6 MPEG adapté pour l'audio et/ou la vidéo. Il est également possible d'ajouter des suppléments descriptifs du fichier sonore au format AIFF connu de l'homme du métier. Ce format sonore choisi est par exemple Fn. Selon un mode de réalisation avantageux, il est choisi de façon aléatoire parmi un certain nombre formats disponibles.

Les paramètres CLk du fichier client correspondant à l'identification login/ Mot de passe et donc à la machine autorisée sont également envoyés vers ce serveur de clé et de procédé 2. Ce serveur choisit également de préférence de façon aléatoire un procédé de cryptage qui servira à crypter le fichier musical et le fichier exécutable. Ce procédé de cryptage est par exemple choisi de façon non limitative parmi les procédés connus du type DES, AES ou Blowfish. Pour augmenter la sécurité, on peut également utiliser une combinaison de plusieurs procédés de cryptage.

On génère également une clé aléatoire de cryptage qui sera aussi associée au fichier musical, ainsi qu'aux paramètres du client.

Cette clé aléatoire correspond par exemple au fichier exécutable lui-même, de telle sorte que si le fichier est modifié (par exemple si on désire modifier les autorisations d'accès), la clé sera automatiquement modifiée.

On suppose que le cryptage choisi correspond à un procédé de cryptage Pi, choisi parmi un ensemble P1, ...,Pn , que la clé de cryptage générée est C] et que le format musical est Fn. Dans ce cas, le fichier son est envoyé au niveau d'un serveur de livraison 3 sous la forme d'un fichier son au format Fn crypté selon Pi, Ci et CLk. Le fichier son comprend par exemple une zone d'identification des procédés, des clés et des formats sonores, dans laquelle sont indiqués les procédés et les clés utilisées, ici Pi, Ci, CLk et Fn. Le serveur de livraison comprend alors un programme de type JAR (Java Archive) destiné selon l'invention, à encapsuler le fichier son crypté.

Comme illustré figure 3, on crée donc au niveau du serveur de livraison 3, un fichier exécutable comprenant une partie de code java permettant de décrypter les fichiers sonores selon des procédés de lectures P1, ..., Pn. Il comprend donc des composants java, ou classes, de décryptage de ces différents procédés, ainsi que les différents composants permettant de lire les formats musicaux. Il comprend également le fichier son crypté selon le procédé Pi, la clé Ci et l'identifiant du client CLk. C'est ce fichier exécutable qui est livré au client désirant télécharger une musique choisie.

L'homme du métier comprendra donc que selon la présente invention, le moyen de lecture et de décryptage du son téléchargé est livré en même temps que le son, et que, selon les clés générées aléatoirement, les procédés générés aléatoirement et les identifiants du poste client, ce lecteur est différent à chaque utilisation. A la différence des solutions de l'art antérieur qui délivrent un fichier sonore dans un certain format, la présente invention délivre un fichier exécutable.

La combinaison des différents éléments de cryptage est donc associé de façon unique au fichier musical destiné à être lu. 8 Selon un mode de réalisation particulièrement avantageux, les classes java du programme de lecture correspondant à l'exécutable téléchargé sont invisibles et tous les noms de classes sont remplacés par des variables anonymes. On utilise par exemple pour cela la méthode proguard disponible dans le public.domain.class java. Ceci améliore encore la protection du programme et la difficulté d'atteindre les procédés de cryptages choisis ainsi que classes de lectures associées.

Comme illustré figure 4, une fois téléchargé sur une machine comprenant une machine virtuelle java (Interpréteur Java) ce programme de lecture de type .jar, comprenant le fichier sonore, peut être exécuté. Lors de l'ouverture du fichier .jar par l'interpréteur, le programme commence de préférence par interroger la machine sur laquelle il est installé. Si cette machine ne correspond pas aux paramètres du fichier client, l'ouverture du fichier son n'est pas réalisée, celui-ci ne peut pas être lu. Selon d'autres modes de réalisation, en cas de comparaison négative (c'est-à-dire si la machine sur laquelle on exécute le programme n'est pas celle à laquelle était destinée le fichier musical), le fichier peut être également lu de façon dégradé, ou lu seulement pendant un temps prédéfini.

L'homme du métier comprendra également que l'exécutable .jar utilisé ici n'est pas limitatif pour l'invention, et tout exécutable multi-plateforme peut être utilisé.

L'exécutable .jar possède en fait l'avantage de pouvoir être utilisé sur les téléphones mobiles, et le procédé selon l'invention est applicable également pour le téléchargement de sonneries de portable. Encore une fois, tout exécutable compatible avec les appareils de téléphonies pourrait être utilisé.

Si les paramètres de machines correspondent au fichier client du programme, celui-ci commence par appeler la classe correspondant au procédé de cryptage du fichier son Pi. Il décrypte également le fichier son à l'aide de la clé aléatoire Ck et de l'identifiant client CL]. Ces différents paramètres sont obtenus sur requête du programme vers la partie de l'exécutable comprenant les paramètres du fichier son crypté.

L'étape de décryptage du fichier pour le procédé Pi est réalisée de manière connu pour les fichiers exécutables de type .jar, par un premier SPI (Sound Provider Interface) associé au procédé Pi. Un second SPI réalise alors la conversion dans le format PCM lisible par le logiciel Java Sound. Il est entendu que les SPI nécessaires à ces conversions sont présents dans le fichier .jar selon l'invention. L'exécutable comprend également les SPI nécessaires à la lecture du fichier sonore dans un format sonore de type MP3, OGG-VORBIS, ou MPEG. L'homme du métier comprendra que ce fichier exécutable est autonome au sens où il comprend toutes les classes correspondant à son fonctionnement.

L'utilisateur peut alors entendre la musique commandée.

L'homme du métier comprendra facilement les avantages de la présente invention dans le cas d'un transfert des fichiers reçus d'une machine à une autre.

Par exemple, si un utilisateur 1, inscrit au service sa machine A. Il utilise sa machine A pour télécharger le fichier exécutable selon l'invention contenant un fichier audio. Le fichier exécutable reconnaissant sa machine, celui-ci pourra être lu sans difficulté grâce à la machine virtuelle.

Si le programme contenant le son est maintenant transmis à une seconde machine, par exemple à l'aide d'une clé USB, la tentative d'identification de la machine sera infructueuse, et le fichier ne pourra pas être joué. Cette machine ne correspond en effet pas à la machine sur laquelle le fichier sonore est destiné à être lu.

L'homme du métier comprend que ceci est rendu possible grâce à la présente invention puisque le programme de décryptage et de lecture est lui-même associé à la machine de l'utilisateur, ainsi qu'au fichier musical choisi.

Au contraire, dans les procédés connus, les lecteurs n'étant pas associés spécifiquement aux morceaux choisis, des morceaux non identifiés et obtenus illicitement peuvent être lus une fois la clé du lecteur connue.

A la lecture de la description ci-dessus, on comprend que le fichier numérique représentant des données audio et/ou vidéo peut être remplacé par tout type de flux numérique, et correspond en fait à un accès à tout type de 30 flux numérique. La présente invention est en particulier utilisable dans le cas du streaming (lecture en transit) en remplaçant par exemple le fichier audio par une URL ou URI d'où provient le flux. Tout flux local ou distant est donc utilisable en association avec la présente invention.

Enfin, la présente invention peut être inséré dans un explorateur de fichier pour pouvoir choisir de façon aisée les différents exécutables comportant les musiques commandée.

L'invention est décrite dans ce qui précède à titre d'exemple. Il est entendu que l'homme du métier est à même de réaliser différentes variantes de l'invention sans pour autant sortir du cadre du brevet.

Claims

REVENDICATIONS

1. Procédé de restitution d'un flux numérique 5 sur une machine d'un utilisateur, caractérisé en ce qu'il comprend au moins les étapes consistant à : générer un fichier exécutable comprenant ledit flux numérique crypté, ledit cryptage étant unique pour ledit flux numérique, un moyen de 10 décryptage dudit cryptage unique, un moyen de lecture dudit flux numérique dans son format et au moins un identifiant de la machine sur laquelle ledit flux numérique est destiné à être joué. Exécuter ledit fichier exécutable pour 15 la restitution dudit flux numérique en cas de comparaison positive entre l'identifiant de la machine sur laquelle ledit flux numérique est destiné à être joué et ladite machine de l'utilisateur. 20

2. Procédé de restitution d'un flux numérique selon la revendication 1, caractérisé en ce qu'il comprend en outre une étape préalable d'identification de la machine sur laquelle ledit flux numérique est destiné à être joué. 25

3. Fichier de restitution d'un flux numérique destiné à être joué sur une machine d'un utilisateur caractérisé en ce que ledit fichier est un fichier exécutable comprenant ledit flux numérique crypté, ledit 30 cryptage étant unique pour ledit flux numérique, un moyen de décryptage dudit cryptage unique, un moyen de lecture dudit flux numérique dans son format et au moins un identifiant de la machine sur laquelle ledit flux numérique est destiné à être joué.

4. Fichier de restitution d'un flux numérique selon la revendication 3, caractérisé en ce que ledit cryptage est réalisé par une clé de cryptage.

5. Fichier de restitution d'un flux numérique selon la revendication 3, caractérisé en ce que ledit cryptage est réalisé par un procédé de cryptage.

6. Fichier de restitution d'un flux numérique selon la revendication 4, caractérisé en ce que ladite clé de cryptage est générée aléatoirement.

7. Fichier de restitution d'un flux numérique 15 selon la revendication 4, caractérisé en ce que ladite clé de cryptage correspond à une partie du fichier exécutable lui-même.

8. Fichier de restitution d'un flux numérique 20 selon la revendication 3, caractérisé en ce que ledit procédé de cryptage est choisi de façon aléatoire parmi un ensemble de procédés prédéterminé.

9. Fichier de restitution d'un flux numérique 25 selon la revendication 3, caractérisé en ce que ledit format du flux numérique est choisi de façon aléatoire parmi un ensemble de formats prédéterminé.

10. Fichier de restitution d'un flux 30 numérique selon la revendication 3, caractérisé en ce que ledit fichier comprend un ensemble d'éléments non dissociés. 10 5

11. Fichier de restitution d'un flux numérique selon la revendication 3, caractérisé en ce que ledit fichier comprend un ensemble d'éléments non dissociables. 10