FR 2882210 A1 20060818 FR 0550411 A 20050211 PROCÉDÉ DE PROTECTION D'UN FICHIER DE DROITS NUMÉRIQUES DESCRIPTION 5 DOMAINE TECHNIQUE L'invention se situe dans le domaine de la protection de ressources et de contenus numériques par la technique de Gestion des Droits Numériques GDN ou DRM (pour Digital Right Management). Plus spécifiquement, l'invention concerne un procédé de protection d'un fichier contenant une pluralité de descriptions de droits Di (i=1 N, N étant un nombre entier), chaque droit Di définissant l'usage par un terminal d'au moins une ressource et/ou un contenu numérique parmi une pluralité de ressources et/ou contenus numériques RCj (j=1 M, M étant un nombre entier) distribués ou mis à la dispositions d'un ou de plusieurs usagers équipés de terminaux multimédia, chaque description d'un droit donné Di comportant, notamment, un identifiant dudit droit Di, un identifiant de chaque ressource et/ou contenu RCi dont l'usage est défini par ledit droit Di et les conditions d'usage desdites ressources et/ou desdits contenus RC L'invention concerne également un terminal multimédia comportant, une zone mémoire non sécurisée, une zone mémoire sécurisée et un processeur de sécurité, ladite zone mémoire non sécurisée étant destinée à stocker au moins un fichier contenant une pluralité de descriptions de droits D,_ (i=1 N) définissant chacun l'usage d'au moins une ressource et/ou un contenu numérique parmi une pluralité de ressources et/ou contenus numériques RCj (j=1 M) chaque description d'un droit Di donné comportant, notamment, un identifiant dudit droit Di, un identifiant de chaque ressource et/ou contenu RCi dont l'usage est défini par ledit droit Di, et les conditions d'usage desdites ressources et/ou desdits contenus. Un contenu RC3 est un fichier numérique comprenant notamment un identifiant et des données constituant le document qu'il représente. Ces données peuvent representer un ou plusieurs programmes audiovisuels ou multimédia. Ces programmes peuvent être distribués en clair, ou embrouillés par une clé secrète mémorisée de manière sécurisée dans le terminal. Une ressource RCJ peut être une fonction informatique du terminal telle que par exemple un programme de gestion d'annuaire personnel, ou un dispositif périphérique connecté au terminal, tel qu'une mémoire de masse de type disque dur par exemple dont l'usage est soumis à des conditions inscrites dans le fichier de droit. Un droit Di est une collection de données décrivant comment un contenu numérique ou une ressource informatique peut être utilisé. Généralement, un droit est décrit dans un documents XML (pour Extensible Markup Language) contenant notamment l'identifiant de ce droit, un attribut (Stateful/Stateless) précisant si le droit se modifie au cours de son utilisation, une ou plusieurs désignations de contenu (Asset) comprenant notamment l'identifiant du contenu (ContentId) et éventuellement le cryptogramme d'une clé CEK permettant le déchiffrement de ce contenu, et une description de permissions et de contraintes indiquant l'usage qui 2882210 3 peut être fait du contenu. La clé peut être chiffrée par une clé dépendante de l'émetteur du droit fournie de façon sécurisée au terminal auquel est destiné le contenu. Le degré de sécurité du contenu ou de la ressource dépend essentiellement du degré de sécurité du droit associé à ce contenu ou à cette ressource. ÉTAT DE LA TECHNIQUE ANTÉRIEURE Les techniques de gestion des droits numériques connues sont basées sur une application DRM utilisant des modules logiciels et matériels pour le traitement d'objets numériques représentants des contenus auxquels sont associés des droits (RightObject) d'usage. Dans les techniques DRM de l'art antérieur, la sécurisation des droits est assurée essentiellement par des solutions logicielles dans lesquelles toutes les informations contenues dans le document XML décrivant un droit sont mémorisées dans un espace public du terminal de l'usager. Aussi, ces informations peuvent être récupérées et altérées et/ou utilisées frauduleusement. Une solution connue dans l'art antérieur consiste sécuriser le canal de communication entre l'usager et le fournisseur de contenu au moyen d'une clé de chiffrement mémorisée dans un processeur de sécurité associé au terminal. Cette solution assure uniquement une protection au niveau du transport, et ne permet pas de protéger le droit lorsque ce dernier est reçu et stocké dans la mémoire du terminal. Par ailleurs, compte tenu de la grande taille d'un fichier de droit et de la puissance du langage de sa description au format XML, il est difficile de stocker ce fichier dans un processeur de sécurité et d'effectuer des traitements sur le droit en raison de la capacité mémoire et de la puissance de traitement limitées des processeurs de sécurité actuels. Aussi, un but de l'invention est de d'améliorer le niveau de sécurité du droit associé à un contenu ou à une ressource, en tenant compte des limitations de puissance de traitement et de capacité de stockage de celui-ci. EXPOSÉ DE L'INVENTION Ce but est atteint au moyen d'un procédé basé sur une application DRM dans lequel les informations sensibles d'un document de droit sont extraites de ce document pour être traitées de façon sécurisée. A cet effet, l'invention préconise un procédé de protection d'un fichier contenant une pluralité de descriptions de droits Di (i=1... N), chaque droit Di définissant l'usage par un terminal d'au moins une ressource et/ou contenu numérique parmi une pluralité de ressources et/ou contenus numériques RCj (j=1 M), chaque description d'un droit Di donné comportant, notamment, - un identifiant dudit droit DI, -un identifiant de chaque ressource et/ou contenu RO] dont l'usage est défini par ledit droit DI, - les conditions d'usage desdites ressources et/ou desdits contenus par le terminal. Le procédé selon l'invention comporte les étapes suivantes à la réception du fichier des descriptions de droits Di par un terminal: -mémoriser lesdites descriptions dans le terminal, et, - générer pour chaque ressource et/ou contenu RCj une structure de donnée (IdRC3, Id_Di), comportant l'identifiant de ladite ressource et/ou dudit contenu et l'identifiant de chaque droit définissant un usage dudit contenu RCJ, transférer chaque structure (IdRC, Id_Di) générée dans une zone mémoire sécurisée. Les étapes du procédé selon l'invention sont exécutées de façon transparente pour l'utilisateur du terminal par un logiciel de l'application DRM, appelé agent DRM dans la suite de la description. Le procédé selon l'invention comporte en outre une étape consistant à vérifier, avant chaque transfert d'une structure (IdRCj, Id_Di) dans la zone mémoire sécurisée, qu'il n'existe pas déjà dans cette mémoire securisée une structure comportant l'identifiant du droit Di. Cette étape permet d'éviter de modifier directement sans effacement préalable un droit existant ou d'associer frauduleusement un nouveau contenu à un droit existant. En outre, le procédé selon l'invention comporte des étapes exécutées dans un environnement sécurisé visant à assurer l'intégrité du droit associé au contenu ou à la ressource dont l'usage est demandé par l'utilisateur du terminal. Ces étapes consistent à: - calculer un condensé cryptographique de chaque description de droit Di, - générer un couple (Id Di, Cnd Di) comportant l'identifiant du droit Di et le condensé cryptographique de la description de ce droit, - transférer le couple généré dans ladite zone mémoire sécurisée. Le stockage du couple (Id Di, Cnd Di) dans la zone mémoire sécurisée permet de disposer d'une référence pour constater ultérieurement toute tentative de modification frauduleuse du droit associé à un contenu. Lorsqu'un utilisateur requiert l'usage d'un contenu et/ou d'une ressource donné RCk, l'agent DRM 10 exécute une phase de contrôle préalable consistant à vérifier que. - l'identifiant d'au moins un droit Dm est associé à l'identifiant de ladite ressource et/ou contenu RCk dans la zone mémoire sécurisée, et -la description du droit Dm correspond à l'usage souhaité. Pour l'usage requis, la phase de contrôle comporte en outre une étape consistant à recalculer un condensé cryptographique Cndc Dm du droit Dm mémorisé dans le terminal et à comparer le condensé Cndc Dm obtenu avec le condensé Cnd Dm du droit Dm associé à l'identifiant de ladite ressource et/ou contenu RCk dans la zone mémoire sécurisée. Le procédé selon l'invention comporte en outre une phase d'autorisation exécutée par l'agent DRM quand le contenu RCk est embrouillé et consistant, dans une première variante de réalisation, à récupérer la clé secrète si l'identifiant d'un droit Dm est associé à l'identifiant dudit contenu RCk dans la zone mémoire sécurisée, et si la description du droit Dm correspond à l'usage souhaité. Dans une deuxième variante de réalisation, ladite phase d'autorisation consiste à récupérer la clé secrète si, en plus, le condensé cryptographique recalculé Cndc_Dm est identique au condensé cryptographique mémorisé Cn Dm dans la zone mémoire sécurisée, et si la description du droit Di correspond à l'usage souhaité. Dans une troisième variante de réalisation, lorsque la ressource protégée est un logiciel et/ou un dispositif matériel, la phase d'autorisation d'usage de cette ressource consiste à exécuter ledit logiciel et/ou actionner ledit dispositif si l'identifiant d'un droit Dm est associé à l'identifiant de ladite ressource RCk dans la zone mémoire sécurisée, et si la description du droit Dm correspond à l'usage souhaité. Dans une quatrième variante de réalisation, si la ressource est un logiciel et/ou un dispositif matériel, ladite phase d'autorisation consiste à exécuter ledit logiciel et/ou actionner ledit dispositif si le condensé cryptographique Cndc Dm recalculé est identique au condensé cryptographique mémorisé Cn Dm dans la zone mémoire sécurisée, et si la description du droit Dm correspond à l'usage souhaité. Le terminal selon l'invention comporte: - des moyens logiciels et/ou matériels pour générer, à partir de la description de chaque droit Di et pour chaque ressource et/ou contenu RCj identifié(e) dans ledit droit, une structure de donnée (IdRCj, Id_Di) comportant l'identifiant de ladite ressource et/ou dudit contenu et l'identifiant dudit droit, - des moyens pour transférer chaque structure générée dans une zone mémoire sécurisée. Préférentiellement, le terminal selon l'invention comporte en outre: des moyens logiciels et/ou matériels pour calculer un condensé cryptographique Cnd_Di de chaque description de droit Di, - des moyens pour générer un couple (Id Di, Cnd Di) comportant l'identifiant du droit Di et le condensé cryptographique de la description de ce droit. La zone mémoire sécurisée du terminal peut être une partie de la mémoire du terminal ou encore une mémoire agencée dans le processeur de sécurité. Ce dernier est préférentiellement une carte à puce amovible. BRÈVE DESCRIPTION DES DESSINS D'autres caractéristiques et avantages de l'invention ressortiront de la description qui va suivre, prise à titre d'exemple non limitatif, en référence aux figures annexées dans lesquelles: - la figure 1 illustre schématiquement l'architecture générale d'un terminal dans lequel est mis en oeuvre le procédé selon l'invention. - la figure 2 est un organigramme représentant les étapes de sécurisation d'un droit dans un mode préféré de réalisation du procédé selon l'invention, - la figure 3 est un organigramme représentant les étapes de vérification d'un droit d'usage d'une ressource et/ou d'un contenu dans une première variante de mise en oeuvre du procédé selon l'invention. - la figure 4 est un organigramme représentant les étapes de vérification d'un droit d'usage d'une ressource et/ou d'un contenu dans une deuxième variante de mise en oeuvre du procédé selon l'invention. EXPOSÉ DÉTAILLÉ DE MODES DE RÉALISATION PARTICULIERS La description qui va suivre concerne une application particulière du procédé selon l'invention pour protéger le droit d'usage de programmes multimédia distribués à plusieurs abonnés. Les droits d'accès à ces programmes sont gérés par une application DRM installée dans les terminaux d'abonnés. L'application DRM comporte un module logiciel 1, appelé agent DRM dans la suite de cette description, chargé d'exécuter les étapes de sécurisation et de contrôle des droits d'usage des programmes multimédia. Ces derniers peuvent être en clair ou embrouillés par une clé secrète mémorisée dans une carte à puce associé au terminal. La distribution des programmes peut être effectuée par téléchargement sur les terminaux des abonnés via par exemple le réseau Internet, une liaison xDSL ou un réseau téléphonique, ou par diffusion via par exemple un réseau hertzien ou câblé. Les programmes peuvent également être distribués sur des supports d'enregistrement tels que exemple des CD (Compact Disc) ou des DVD (digital Video Disc) sans sortir du cadre de l'invention. Bien entendu, le procédé ne se limite pas à ce type de contenu et s'applique à la sécurisation et au contrôle des droits d'usage de toute ressource, logicielle ou matérielle, dont l'usage est régi par des droits Di décrits dans un fichier numérique. Chaque description d'un droit Di donné comporte, notamment, un identifiant dudit droit Di, un identifiant de chaque ressource et/ou contenu RC3 dont l'usage est défini par ledit droit Di, et les conditions d'usage desdites ressources et/ou desdits contenus. La figure 1 représente schématiquement l'architecture d'un terminal d'abonné comportant un agent DRM 1, un lecteur de carte à puce 2 destiné à recevoir une carte à puce 3 spécifique à l'abonné et dotée d'une mémoire sécurisée 9 et d'une zone de traitement sécurisée 11, une zone mémoire 4 destinée à stocker des fichiers de droits contenant une pluralité de descriptions de droits Di (i=1 N) définissant chacun l'usage des programmes multimédia, un module de contrôle 6 desdits droits, un module de traitement des droits 7 contenant des logiciels qui coopèrent avec l'agent DRM 1 pour sécuriser les droits Di, et un lecteur multimédia 8 permettant l'exécution desdits programmes multimédias. Le terminal comporte en outre une sortie audio 10 et un écran d'affichage 12. SÉCURISATION DES DROITS A la réception du fichier des descriptions de droits par le terminal, la phase de sécurisation est initialisée par l'agent DRM. L'agent DRM mémorise lesdites descriptions dans le terminal et, pour chaque description de droit, il génère pour chaque programme multimédia identifié dans ledit droit une structure de donnée (Id_RC3, IdDi) comportant l'identifiant Id_RC3 dudit programme et l'identifiant Id Di dudit droit. Ensuite, l'agent DRM transfère chaque structure générée dans la mémoire sécurisée 9 de la carte à puce 3. Les étapes de la phase de sécurisation vont maintenant être décrite en détail par référence à la figure 2. A la réception d'un fichier de droits Di (i=1 N), pour chaque droit Di, le module de traitement des droits 7 vérifie, à l'étape 14, si la mémoire sécurisée 9 de la carte à puce 3 ne contient pas déjà au moins un couple (Id_RCX, Id Di) référençant le droit Di. Si oui, le processus de sécurisation est interrompu pour ce droit Di. Sinon, à l'étape 15, le module de traitement des droits 7 transfère la description du droit Di dans la mémoire 4 du terminal. Puis, pour chaque programme multimédia RCk identifié dans ledit droit Di, à l'étape 16, le module de traitement des droits 7 génère une structure (Id RCk, Id Di) et mémorise la structure générée dans la mémoire sécurisée 9 de la carte à puce 3. Cette structure (Id RCk, Id Di) comporte l'identifiant du programme multimédia RCk et l'identifiant du droit Di référençant ce programme. Si une autre structure référençant le programme RCk associé à un autre droit DZ existe déjà, la structure générée peut être combinée avec cette autre structure sous la forme (Id RCk, Id Di, Id DZ), cette combinaison étant itérative. Si le programme RCj est embrouillé (étape 17), le module de traitement des droits mémorise à l'étape 18 la clé de désembrouillage CEK du programme reçue sous forme chiffrée dans le droit Di. Dans un premier mode de réalisation, la clé de désembrouillage CEK du programme RCi est extraite du droit Di et déchiffrée selon les paramètres propres au droit, puis elle est transférée dans la mémoire sécurisée 9 de la carte à puce en association avec l'identifiant du programme. Dans un deuxième mode de réalisation, la clé de désembrouillage CEK du programme RCi est extraite du droit Di et déchiffrée selon les paramètres propres au droit, puis elle est chiffrée dans la zone de traitement sécurisée 11 avec une clé secrète mémorisée dans la mémoire sécurisée 9 de la carte à puce. Le cryptogramme obtenu est transféré dans la mémoire 4 du terminal en association avec l'identifiant du programme. Dans un troisième mode de réalisation, la clé de désembrouillage CEK du programme RO] est laissée, sans être déchiffrée, dans la description du droit Di mémorisée dans la mémoire 4 du terminal. Dans un mode préféré de mise en oeuvre du procédé, le module de traitement des droits 7 calcule dans la zone de traitement sécurisée 11, à l'étape 19, un condensé cryptographique Cnd Di du droit Di et mémorise le couple (Id Di, Cnd Di) dans la mémoire sécurisée 9 de la carte à puce 3. USAGE DES PROGRAMMES MULTIMÉDIA Lorsqu'un utilisateur sélectionne un programme multimédia RCk (vidéo et/ou audio ou jeu), en cliquant par exemple sur une icône représentant ce programme, il déclenche le démarrage du lecteur multimédia 8. Le lecteur 8 récupère le programme sélectionné et le soumet à l'agent DRM 1. Ce dernier consulte la base de définitions des droits stockée dans la mémoire 4, identifie le(s) droit(s) convenant au programme multimédia sélectionné et soumet ensuite ce(s) droit(s) au module de contrôle 6 qui effectue le contrôle de leur(s) existence(s) et de leur(s) validité(s). L'agent DRM 1 sélectionne en outre le meilleur droit parmi ces droits identifiés, avant ou après les contrôles effectués par le module de contrôle 6. La figure 3 représente schématiquement un premier mode de contrôle de l'existence et de la validité d'un droit associé au programme sélectionné RCk. Dans ce cas, le module de contrôle 6 recherche préalablement, à l'étape 20, dans la mémoire 4 du terminal un droit Dm conforme à l'usage demandé par l'utilisateur du programme multimédia Si aucun droit conforme à la requête de l'utilisateur n'est disponible dans la mémoire 4, l'usage est interdit. Si un droit Dm conforme à la requête de l'utilisateur est présent dans la mémoire 4, le module de contrôle vérifie ensuite, à l'étape 22, si le couple (Id RCk,Id Dm) est présent dans la mémoire sécurisée 9 de la carte à puce 3. Si ce couple (Id RCk,Id Dm) n'est pas présent dans la mémoire sécurisée de la carte à puce, alors l'usage est interdit. Sinon, optionnellement, le module de contrôle 6 calcule dans la zone de traitement sécurisé 11, à l'étape 24, un condensé cryptographique Cndc Dm du droit Dm dont la description est mémorisée dans la mémoire du terminal 4 et compare ce condensé calculé Cndc Dm au condensé Cnd Dm préalablement transféré dans la mémoire sécurisée 9 de la carte à puce lors de la phase de sécurisation. Si le condensé calculé Cndc Dm n'est pas identique au condensé Cnd_Dm stocké dans la mémoire sécurisée 9 de la carte à puce, alors l'usage est interdit. Si le condensé calculé Cndc Dm est identique au condensé Cnd Dm, ou si le contrôle du condensé du droit Dm n'est pas effectué, le module de contrôle 6 vérifie, à l'étape 28, si le programme multimédia est embrouillé ou non. Si le programme multimédia est embrouillé, le module de contrôle 6 récupère, à l'étape 30, la clé CEK de désembrouillage du programme et envoie, à l'étape 32, au lecteur multimédia 8 une autorisation d'usage du programme désembrouillé. Dans un premier mode de réalisation, la clé de désembrouillage CEK est extraite de la mémoire sécurisée 9 de la carte à puce 3 où elle a été mémorisée en association à l'identifiant du contenu Id RCk lors de sécurisation du droit Dm. Dans un deuxième mode de réalisation, la clé de désembrouillage CEK est obtenue à partir de son cryptogramme mémorisé dans la mémoire 4 du terminal. Ce cryptogramme est déchiffré dans la zone de traitement sécurisé 11 de la carte à puce avec une clé secrète stockée dans la mémoire sécurisée de la carte à puce. Dans un troisième mode de réalisation, le cryptogramme de la clé de désembrouillage CEK est extrait de la description du droit Dm mémorisée dans la mémoire 4 du terminal et la clé de désembrouillage est obtenue par déchiffrement de ce cryptogramme selon des paramètres présents dans la description du droit Dm. Si le programme multimédia n'est pas embrouillé, le module de contrôle 6 exécute directement l'étape 32. Après l'usage du programme, le droit Dm peut avoir été modifié (attribut Stateful/Stateless), par exemple quand le droit permet l'usage du programme un nombre limité de fois, le nombre d'usages effectués étant décrémenté dans le droit à chaque usage. Dans ce cas, à l'étape 34, la description du droit mémorisée dans la mémoire 4 du terminal est mise à jour. En outre, à l'étape 36, si le condensé du droit Cnd Dm existe dans la mémoire sécurisée 9, il est recalculé dans la zone de traitement sécurisé 11 et mis à jour dans la mémoire sécurisée 9 de la carte à puce. La figure 4 représente un deuxième mode de contrôle de l'existence et de la validité d'un droit associé au programme sélectionné RCk. Dans ce mode, à l'étape 40, le module de contrôle 6 recherche dans la mémoire sécurisée 9 de la carte à puce 3 toutes les structures (Id_RCk, Id_DP), p=1... P, générées lors de la phase de sécurisation des droits Di et relatives au programme RCk et constitue une liste des identifiants de droits Id_Dj presents dans les structures trouvées. A l'étape 42, le module de contrôle 6 vérifie si la liste (Id_DP, p=1 P) créée contient au moins un droit Dm permettant l'usage souhaité par l'utilisateur. Si un tel droit n'existe pas dans la mémoire de la carte à puce, l'usage est interdit. Si un tel droit existe dans la mémoire de la carte à puce, le module de contrôle 6 exécute des étapes 44 à 56 identiques aux étapes 24 à 36 de la figure 3. Avantageusement, l'agent DRM peut supprimer de la mémoire de la carte à puce toutes les informations relatives à un droit périmé. Cette opération peut être précédée d'une authentification de l'utilisateur de la carte à puce. Cette opération peut aussi être conditionnée par le calcul du condensé du droit à supprimer et par le contrôle que ce condensé calculé est égal au condensé de ce droit mémorisé dans la mémoire sécurisée 9 de la carte à puce 3. L'invention peut être mise en uvre dans un téléphone mobile muni d'une carte SIM (pour Subscriber Identity Module). Dans ce cas, les structures de données (Id_RC3,IdD _) reliant l'identifiant du contenu et l'identifiant du droit et les structure de données (Id Di, Cnd Di) reliant l'identifiant d'un droit et le condensé cryptographique de ce droit sont mémorisées sous forme de tables dans la carte SIM. Dans une autre variante de mise en oeuvre, ces structures de données sont mémorisées dans une zone mémoire sécurisée située sur un réseau et l'accès à cette zone sécurisée est effectué par un canal protégé. Selon une caractéristique supplémentaire du procédé, la zone mémoire sécurisée, dans le réseau, dans la carte à puce, ou dans la carte SIM, comporte un paramètre de date qui est mis à jour avec la date courante à chaque accès en écriture ou en lecture à la zone mémoire sécurisée. Toute tentative d'accès à la mémoire sécurisée à une date courante inférieure à celle contenue dans ce paramètre de date sera invalidée de manière à éviter un usage par anti-datage du terminal. Le procédé selon l'invention permet de: - garantir qu'un droit a bien été acquis légalement et ceci avec une garantie de sécurité élevée. vérifier que le droit n'a pas été altéré depuis sa dernière utilisation, car une vérification d'intégrité du droit dans la zone mémoire sécurisée peut être effectuée à chaque utilisation du droit, d'accélérer la vérification des droits, dans la mesure où le droit est syntaxiquement analysé par le terminal qui généralement dispose d'une capacité de traitement supérieure à celle d'un processeur de sécurité. - d'assurer une capacité de stockage élevé de droits tout en garantissant une sûreté de leur utilisation, puisque seul le condensé du droit est stocké dans la zone mémoire sécurisée, le droit étant stocké dans le terminal (sur le disque dur par exemple) sans protection particulière d'augmenter la confiance dans l'intégrité du droit et donc de la preuve du droit dans la mesure où le calcul du condensé est effectué par le processeur de sécurité. REVENDICATIONS 1. Procédé de protection d'un fichier contenant une pluralité de descriptions de droits Di (i=1 N), chaque droit Di définissant l'usage par un terminal d'au moins une ressource et/ou un contenu numérique parmi une pluralité de ressources et/ou contenus numériques RC3 (j=1 M), chaque description d'un droit Di donné comportant, notamment, - un identifiant dudit droit Di, - un identifiant de chaque ressource et/ou contenu RC3 dont l'usage est défini par ledit droit Di, - les conditions d'usage desdites ressources et/ou desdits contenus par le terminal, procédé caractérisé 15 en ce qu'il comporte les étapes suivantes: à la réception du fichier de descriptions des droits Di par un terminal, - mémoriser lesdites descriptions dans le terminal, et, - générer, pour chaque ressource et/ou contenu RC3, une structure de donnée (IdRC3, Id Di) comportant l'identifiant de ladite ressource et/ou dudit contenu et l'identifiant de chaque droit Di définissant un usage de ladite ressource et/ou dudit contenu RCj, - transférer chaque structure (IdRC3, Id Di) générée dans une zone mémoire sécurisée. 2. Procédé selon la revendication 1, caractérisé en ce qu'il comporte en outre les étapes suivantes: - calculer de manière sécurisée un condensé cryptographique Cnd_Di de chaque description de droit Di, -générer de manière sécurisée un couple (Id Di, Cnd Di) comportant l'identifiant du droit Di et le condensé cryptographique de la description de ce droit, transférer le couple (Id_Di, Cnd_Di) généré dans la zone mémoire sécurisée. 3. Procédé selon la revendication 1, caractérisé en ce qu'il comporte en outre une étape consistant à vérifier, avant le transfert dans la zone mémoire sécurisée de toutes les structures (IdRCj,IdD1) issues du traitement d'un même droit Di, qu'il n'existe pas déjà dans cette mémoire une structure comportant l'identifiant Id Di du droit Di. 4. Procédé selon la revendication 1, caractérisé en ce qu'il comporte une phase de contrôle préalable à un usage d'une ressource et/ou d'un contenu donné RCk consistant à vérifier que: - l'identifiant d'au moins un droit Dm est associé à l'identifiant Id RCk de ladite ressource et/ou contenu RCk dans la zone mémoire sécurisée, et que - la description du droit Dm correspond à l'usage souhaité. 5. Procédé selon la revendication 2, dans lequel, pour l'usage requis par le terminal de la ressource et/ou du contenu RCk, la phase de contrôle comporte en outre une étape consistant à recalculer un condensé cryptographique du droit Dm mémorisé dans le terminal et à comparer le condensé obtenu Cndc Dm avec le condensé CndDm dudit droit Dm préalablement transféré dans la zone mémoire sécurisée. 6. Procédé selon la revendication 1, dans lequel la ressource RC3 est une fonction informatique du terminal. 7. Procédé selon la revendication 1, dans lequel la ressource RC3 est un dispositif périphérique connecté au terminal. 8. Procédé selon la revendication 1, dans 10 lequel le contenu numérique RCi est un programme audiovisuel ou multimédia en clair. 9. Procédé selon la revendication 1, dans lequel le contenu numérique RO] est un programme audiovisuel ou multimédia embrouillé par une clé secrète mémorisée de manière sécurisée dans le terminal. 10. Procédé selon les revendications 4 et 9, caractérisé en ce qu'il comporte en outre une phase d'autorisation consistant à récupérer la clé secrète si l'identifiant d'un droit Dm est associé à l'identifiant du contenu RCk dans la zone mémoire sécurisée, et si la description du droit Dm correspond à l'usage souhaité. 11. Procédé selon les revendications 5 et 9, caractérisé en ce qu'il comporte en outre une phase d'autorisation consistant à récupérer la clé secrète si le condensé cryptographique recalculé Cndc Dm est identique au condensé Cnd Dm mémorisé dans la zone mémoire sécurisée, et si la description du droit Dm correspond à l'usage souhaité. 12. Procédé selon les revendications 4 et 8, caractérisé en ce qu'il comporte en outre une étape d'autorisation consistant à actionner un dispositif matériel ou logiciel pour accéder au contenu si l'identifiant Id Dm d'un droit Dm est associé à l'identifiant Id RCk dudit contenu RCk dans la zone mémoire sécurisée, et si la description du droit Dm correspond à l'usage souhaité. 13. Procédé selon les revendications 5 et 8, caractérisé en ce qu'il comporte en outre une étape d'autorisation consistant à actionner un dispositif matériel ou logiciel pour accéder au contenu si le condensé cryptographique recalculé CndcD, est identique au condensé mémorisé Cnd_Dm dans la zone mémoire sécurisée, et si la description du droit Dm correspond à l'usage souhaité. 14. Procédé selon la revendication 9, dans 20 lequel ladite clé secrète est chiffrée par une deuxième clé mémorisée dans la zone mémoire sécurisée. . 15. Procédé selon la revendication 9, dans lequel ladite clé secrète est mémorisée en clair dans la zone mémoire sécurisée. 16. Procédé selon la revendication 1, dans lequel ladite zone mémoire sécurisée est agencée sur un processeur de sécurité associé au terminal. 17. Procédé selon la revendication 16, dans lequel ledit processeur de sécurité est une carte à puce. 18. Terminal multimédia comportant, une zone mémoire non sécurisée (4), une zone mémoire sécurisée et un processeur de sécurité (3) , ladite zone mémoire non sécurisée (4) étant destinée à stocker au moins un fichier contenant une pluralité de descriptions de droits Di (i=1 N) définissant chacun l'usage d'au moins une ressource et/ou un contenu numérique parmi une pluralité de ressources et/ou contenus numériques RCj (j=1... M), chaque description d'un droit Di comportant, notamment, un identifiant dudit droit Di, un identifiant de chaque ressource et/ou contenu RC3 dont l'usage est défini par ledit droit Di, et les conditions d'usage desdites ressources et/ou desdits contenus, terminal caractérisé en ce qu'il comporte en outre: - des moyens pour générer, pour chaque ressource et/ou contenu RCj, une structure de donnée (Id_RCj, Id_Di), comportant l'identifiant de ladite ressource et/ou dudit contenu et l'identifiant de chaque droit Di décrivant un usage de ladite ressource RC3, - des moyens pour transférer chaque structure générée dans une zone mémoire sécurisée. 19. Terminal selon la revendication 18, caractérisé en ce qu'il comporte en outre: - des moyens pour calculer un condensé cryptographique Cnd Di de chaque description de droit Di, - des moyens pour générer un couple (Id Di, Cnd Di) comportant l'identifiant du droit Di et le condensé cryptographique de la description de ce droit, - des moyens pour transférer le couple généré dans ladite zone mémoire sécurisée. 26057 /HM 2882210 20. Terminal selon la revendication 19, caractérisé en ce que ladite zone mémoire sécurisée est agencée dans le processeur de sécurité. 21. Terminal selon la revendication 20, caractérisé en ce que ledit processeur de sécurité est une carte à puce amovible. 22. Terminal selon l'une des revendications 18 ou 19, caractérisé en ce qu'il consiste en un téléphone mobile.