FR2891932A1 - Procede d'encapsulation de donnees numeriques dans un conteneur virtuel utilisable par une pluralite d'utilisateurs, et systeme utilisant un tel conteneur virtuel en ecriture ou en lecture - Google Patents

Abstract

L'invention concerne un système et un procédé d'encapsulation de données numériques constituant un contenu informatique, musical ou audiovisuel. Ce procédé permet une utilisation souple de ce contenu par différents utilisateurs selon des droits d'accès différents, tout en sécurisant le respect des droits intellectuels attachés à ce contenu. Ce procédé comprend : - une génération d'une clef unique pour chaque utilisateur ;- une réalisation d'une bio-capsule (BC) comprenant :▪ une première partie (PR) descriptives des données ;▪ une deuxième partie (CRACL) signée ou cryptée contenant les droits d'accès (DU1) des utilisateurs et des informations biométriques de référence (MU1) pour lesdits utilisateurs, et▪ une troisième partie (CRIMG) comprenant un conteneur virtuel crypté, dérivé d'une image du conteneur original (IMG) ; et- un stockage de ladite bio-capsule (BC) sur le support matériel de données numériques (DBC).

Description

-1- Procédé d'encapsulation de données numériques dans un conteneur

virtuel utilisable par une pluralité d'utilisateurs, et système utilisant un tel conteneur virtuel en écriture ou en lecture L'invention concerne un procédé d'encapsulation de données numériques constituant un contenu informatique, notamment dans un format musical ou audiovisuel. Ce procédé est utile en particulier pour permettre une utilisation souple de ce contenu par différents utilisateurs, possiblement selon des droits d'accès différents, et tout en sécurisant le respect des droits intellectuels attachés à ce contenu. L'invention propose également un système utilisant de telles bio-capsules, ou réalisant leur encapsulation ou leur extraction. L'invention s'applique à différents types de contenus informatiques, obtenus auprès d'un fournisseur ou d'un éditeur pour un usage limité. En particulier lorsqu'il s'agit du résultat d'un travail de création ou de construction intellectuelle, tel qu'un logiciel informatique ou une oeuvre sonore ou audiovisuelle numérique ou numérisée, l'utilisation d'un tel contenu ee;i limitée par des droits intellectuels cs,ii restent attachés à ce contenu indépendamment de la façon dont il est obtenu et mémorisé.

Du fait de la facilité grandissante avec laquelle un contenu numérique peut être dupliqué ou transmis, le respect de ces droits devient un enjeu important que l'on souhaite souvent pouvoir mieux contrôler. Différentes solutions sont connues pour cela, telles que par exemple une modification du support matériel ou du format de stockage des données pour créer une incompatibilité avec certains moyens de traitement, ou un cryptage de ce contenu selon des protocoles nécessitant une forme quelconque d'autorisation pour être lus et exploités. Cependant, de par leur nature même, ces types de protection interfèrent souvent avec ces moyens et constituent des contraintes gênantes dans les modes d'utilisation de ces contenus, y compris dans le cadre d'une exploitation autorisée. Or, par ailleurs, les technologies et systèmes pouvant utiliser de tels contenus permettent des modes d'utilisation de plus en plus variés et souples. A partir d'un CD ou d'un DVD ou d'un téléchargement, il est par -2- exemple possible d'enregistrer un tel contenu au sein d'un système informatique et de l'intégrer au sein d'une base de contenus. Il est alors possible d'exécuter ce contenu de différentes façons et en différents lieux, par exemple en programmant des choix aléatoires ou par affinités.

Ces contenus peuvent aussi être fournis et/ou gérés à la demande par un prestataire de service, dont la responsabilité peut être engagée dans le respect des droits attachés aux contenus fournis et qui peut rechercher une connaissance de l'utilisation réelle de ces contenus. Un tel prestataire peut aussi vouloir s'assurer que seuls des contenus autorisés, par lui ou par des ayant droits de ce contenu, sont utilisés dans un système service ou qu'il gère ou fournit. De plus, la gestion de ces contenus par système informatique permet également de prévoir des droits d'accès différents pour différents utilisateurs au sein d'un groupe. Il peut s'agir par exemple de définir des restrictions selon l'âge des différentes personnes au sein d'un même foyer familial, ou selon différentes formules d'abonnement souscrites par les clients d'un hôtel. Or, une telle intégration et gestion informaticue est souvent incompatible avec les dispositifs de contrôle actuellement prévus, qui risquent alors soit d'empêcher cette intégration, soit d'être inefficace une fois les contenus intégrés. Un but de l'invention est de pallier tout ou partie de ces inconvénients. Un but important de l'invention est d'obtenir un respect des droits de propriété intellectuelle portant sur les contenus, selon un modèle défini par les ayant-droits. Il s'agit en particulier de permettre : - une attribution de droits différents selon les utilisateurs ; - une sécurisation de ces différents droits, identifications et authentification ; une authentification avant encapsulation ou utilisation. - un suivi des encapsulations ou utilisations des contenus ; Un autre but de l'invention est de permettre une certaine souplesse pour la gestion des contenus, et en particulier : -3- - une identification facile ou automatique des contenus avant encapsulation ou utilisation ; une bonne compatibilité vis à vis des formats dans lesquels les contenus sont fournis.

Pour cela, l'invention propose un procédé pour encapsuler des données numériques contenues dans un conteneur original et destinées à être exploitées à partir d'un support matériel de données numériques par un ou plusieurs utilisateurs physiques prédéterminés se voyant attribués des droits d'accès ou d'exploitation.

Ce procédé comprend : - une génération d'une clef d'utilisateur associée à chaque utilisateur de façon unique ; - une réalisation d'une bio-capsule comprenant : • une première partie comprenant des informations descriptives des données, ^ une deuxième partie signée ou cryptée contenant les droits d'accès conférés à chaque utilisateur et des informations de référence identi'iant lesdits utilisateurs, et • une troisième partie comprenant un conteneur virtuel crypté, dérivé d'une image du conteneur original ; et - un stockage de ladite bio-capsule sur le support matériel de données numériques. Ces informations de références peuvent avantageusement comprendre des informations biométriques de références. 25 Au sein d'un système informatique, les données numériques constituant un contenu à exploiter sont alors encapsulées sous une forme permettant à la fois un traitement souple et individualisé, et à la fois une sécurisation des différents droits affectés à ce contenu et aux utilisateurs. Lorsque l'on souhaite intégrer un nouveau contenu dans un système 30 informatique, il est possible de partir d'un support matériel dans un format standard, par exemple obtenu par exemple sous la forme d'une une image au format ISO 9660 mémorisée sur un CD de musique ou sur un DVD vidéo, et constituant le conteneur original. Cette image peut alors être traitée selon l'invention pour être encapsulée, directement à partir de ses 20 -4- structure et format d'origine, dans une telle bio-capsule constituant un nouveau conteneur. Cette bio-capsule pourra alors être gérée de façon aussi souple qu'une image d'origine au sein d'un système informatique. Du fait que cette bio-capsule incorpore des informations sur les droits et références biométriques de différents utilisateurs, le système de gestion pourra effectuer une vérification complémentaire, voire une identification certaine, lors d'une demande de n'importe quel utilisateur. Selon les variantes ou les situations, la clef unique associée à chaque utilisateur pourra être par exemple : - une donnée issue des informations biométriques de référence de cet utilisateur, ou - une donnée générée spécialement pour cet utilisateur, ou - ou une signature d'un ensemble de données spécifiques à cet utilisateur, ou - une clef obtenue par cryptage d'une clef commune à plusieurs utilisateurs, ce cryptage utilisant comme clef une donnée dépendant de données spécifiques à cet utilisateur. L'invention est particulièrement = vantageuse lorsque la hio.-caps,. "e est stockée au sein d'un système gérant une pluralité de telles bio-capsules.

Selon une particularité de l'invention, la première partie de la biocapsule comprend en outre des informations descriptives de droits de propriété intellectuelle associés aux données numériques du conteneur original. Ces informations de droits de propriété intellectuelle peuvent alors être utilisées par le système ou par un prestataire de service pour vérifier que le contenu est bien utilisé dans des conditions autorisées par le détenteur de ces droits et/ou conforme à un contrat d'utilisation de ce contenu. Ces informations descriptives peuvent aussi définir un modèle de gestion de ces droits de propriété intellectuelle ( Intellectual Property Model ), par exemple pour tenir compte des conditions d'utilisations ou faire évoluer les droits d'accès attachés au contenu au cours du temps ou des utilisations. -5- En particulier, la bio-capsule ainsi obtenue est bien adaptée pour être stockée et utilisée au sein d'un système gérant une pluralité de telles biocapsules. La première partie de la bio-capsule peut en outre comprendre une signature numérique dite d'objet portant sur tout ou partie de la bio- capsule. Dans le même esprit, l'invention propose aussi un système utilisant une telle bio-capsule. Il peut s'agir d'un système comprenant des moyens de traitement de données agencés pour réaliser une bio-capsule par un tel procédé, à partir d'un conteneur original lu sur un support matériel ou reçu par des moyens de communication. Il peut aussi s'agir d'un système comprenant des moyens de traitement de données agencés pour décrypter et exploiter les données numériques d'une bio-capsule réalisée par un tel procédé. Plus particulièrement le décryptage de la troisième partie de la biocapsule utilise au moins une clef d'image, qui est décryptée à partir d'au mc='ns une. crypto-clef d'image. Le décryptage de cette crypto-clef d'image est alors conditionné à une identification ou une authentification réalisée à partir des informations biométriques de référence mémorisées dans la biocapsule et correspondant à au moins un utilisateur disposant des droits adéquats. La clef de cette utilisateur, ou une donnée qui lui est liée, est alors utilisée pour décrypter cette crypto-clef d'image et accéder au contenu.

D'autres particularités et avantages de l'invention ressortiront de la description détaillée d'un mode de mise en oeuvre nullement limitatif, et des dessins annexés sur lesquels : la figure 1 illustre un système de gestion de contenus audiovisuels, gérés par bio-encapsulation selon l'invention ; la figure 2 illustre la structure des données d'un conteneur informatique constituant une bio-capsule selon l'invention ; la figure 3 illustre une opération de bio-encapsulation selon l'invention ; -6- la figure 4 illustre une opération d'extraction d'une bio-capsule selon l'invention ; - la figure 5 illustre selon l'invention un système utilisant des contenus sous forme de bio-capsules dans une installation audiovisuelle et domotique au sein d'un logement privé ; et la figure 6 illustre selon l'invention un système utilisant des contenus sous forme de bio-capsules dans une installation audiovisuelle au sein d'un établissement collectif ou hôtelier. La figure 1 illustre un mode de réalisation de l'invention, dans lequel un système informatique MCH est agencé et programmé pour stocker et exploiter des contenus multimédia, par exemple de la musique ou des films ou des jeux ou autres applications. Ce système informatique MCH est installé et fonctionne sur un site local déterminé, et sous la responsabilité et/ou l'autorité d'une entité physique ou morale ici qualifiée d'autorité d'utilisation AUT ou autorité locale. Cette autorité peut parfois être qualifiée de propriétaire de I'oeuvre ou l'objet dans le contexte d'utilisation , c'est à dire celui qui a reçu un droit d'utilisation de la part des ayant-droits de propriété iritelle.,:}uelle de l'objet logiciel. Ce droit ~1'ut.itàon est en généra' acquis par l'achat d'un support, ou le paiement d'un téléchargement, et peut varier selon de la nature de l'utilisation, par exemple selon qu'il s'agit d'une exécution publique ou privée, ou d'une utilisation professionnelle ou privée. Selon une application typique de l'invention, le site local est un logement privé ou une pièce d'un logement. L'autorité d'utilisation est alors constituée d'une ou plusieurs personnes ayant l'autorité dans ce logement, et disposant des droits d'utilisation d'un certain nombre de contenus, par exemple des CD ou des DVD achetés ou loués pour un usage à titre privé. Cette personne est par exemple un parent qui peut souhaiter déterminer, pour d'autres utilisateurs comme des enfants de son foyer, des droits d'accès différents en fonction des utilisateurs et des contenus et pour chaque combinaison d'utilisateur et d'un contenu. Selon d'autres applications de l'invention, les utilisateurs peuvent être par exemple les résidents d'un hôtel ou d'une résidence, ou les spectateurs d'une salle ou d'un groupe de cabines ou de salles de spectacle. Le site -7- d'utilisation est alors géré par un personnel d'exploitation ou un automate de gestion constituant l'autorité d'utilisation. Les contenus sont stockés sous la forme de bio-capsules au sein d'une base de données de contenus DBC, par exemple mémorisée dans des moyens de mémorisation tel qu'un disque dur d'ordinateur ou possiblement accessible depuis un serveur informatique distant. Lorsqu'un utilisateur UT veut exploiter un contenu, par exemple pour visionner un film stocké dans une bio-capsule BC, il s'identifie auprès de moyens d'identification biométriques BIO et déclenche une commande d'exécution de ce film. En fonction du choix de l'utilisateur ou d'une sélection automatisée, et si l'utilisateur dispose des droits nécessaires pour exploiter le contenu concerné, le système MCH lit la bio-capsule BC dans la base de contenus DBC et réalise une extraction EXTR des données numériques IMG qui y sont encapsulées. Cette extraction renvoie alors ces données numériques telles qu'elles étaient dans le conteneur original, par exemple sous la forme d'une image ISO-9660 pour un DVD audiovisuel. Ces données numériques sont alors jouées par des moyens d'exécution ME adaptés, par exemple ur téléviseur ou une in` allation de hor -.1. cinéma . Les contenus peuvent être intégrés à la base de contenus DBC de diverses façons. Ils peuvent être obtenus sous une forme classique puis encapsulés au sein du système MCH, ou être fournis directement sous la forme de bio-capsules. De façon typique, les données numériques IMG d'un contenu à intégrer sont lues à partir d'un support matériel de données, puis subissent 25 une encapsulation ENC au sein du système de gestion MCH. Ces données numériques IMG peuvent être lues par exemple sur un CDROM ou un DVD-ROM ou une mémoire statique de type mémoire flash ou une cassette numérique K7 de type vidéo ou audio, ou bien être reçues d'un ordinateur COMP en réseau local ou par des moyens de communications 30 COMM depuis un fournisseur de contenu IDVD. Ces moyens de communication peuvent comprendre en particulier l'Internet, mais aussi tous moyens de télécommunication connus tels que le câble, la voie hertzienne, ou une liaison satellite. -8- De plus, ces données numériques peuvent aussi être numérisées au sein du système MCH à partir d'informations analogiques, par exemple lues sur un support matériel analogique (cassette vidéo, cassette audio, disque microsillons, etc.) ou reçues par des moyens de communications analogiques (voie hertzienne, câble vidéo, téléphone, microphone, etc) Dans certaines situations, par exemple selon les utilisateurs ou les types de contenus ou selon les sources de contenu, le fonctionnement du système MCH de gestion des contenus peut utiliser voire nécessiter une intervention de la part d'une entité extérieure au site d'utilisation, en particulier pour encapsuler ENC un nouveau contenu ou pour extraire EXTR un extraire un contenu à partir d'une bio-capsule BC. Une telle entité peut être une entité physique ou morale accessible par des moyens de télécommunications tels que l'Internet, par exemple un serveur informatique.

Une telle entité constituant une autorité de contrôle ACTRL peut par exemple être nécessaire pour autoriser I'encapsulation d'un nouveau contenu, comme décrit plus loin. Cette autorité de contrôle peut en particulier être chargée de vérifier l'authenticité d'un contenu WC., à encapsuler, ou de vérifier la validité des droits de l'autorité d'utilisation vis à vis de la propriété intellectuelle d'un éditeur ou d'un ayant droit. Cette autorité de contrôle peut aussi comptabiliser les provenances ou identifications des contenus à encapsuler. Elle peut aussi comptabiliser les utilisations des différents contenus, en direct au moment de l'extraction ou par relever de données d'historiques mémorisées dans le système MCH.

Cette autorité de contrôle peut être gérée par exemple par des représentants d'ayant-droits de propriété intellectuelle sur les contenus, ou par un prestataire de service gérant le fonctionnement du système ou la fourniture des contenus. Certaines interventions d'entités extérieures peuvent aussi être réalisées par une entité constituant une autorité de confiance ATRUST. Cette autorité de confiance peut intervenir en délégation de l'autorité de contrôle ACTRL, par exemple pour autoriser une extraction de contenu avec un accès fiable et permanent. Cette autorité de confiance ATRUST peut aussi servir d'intermédiaire de confiance vis à vis de l'autorité de contrôle -9- ACTRL ou de l'autorité d'utilisation AUT, par exemple dans des opérations de paiement à distance. Par ailleurs, certaines opérations du système MCH de gestion des contenus peuvent faire appel à un ou plusieurs fournisseurs d'outils logiciels IOUT, accessibles par exemple par l'Internet. Ce fournisseur d'outils peut fournir un service de traitement de certaines données à la demande ou offrir des possibilités de mises à jour de certains outils logiciels utilisés par le système. Les outils concernés peuvent être en particulier des outils de traitement de données biométriques, ou des outils de cryptage ou de décryptage. En particulier, ces outils peuvent être agencés de façon à pouvoir être changés facilement ou pluggés . Il est alors possible de faire varier le fonctionnement de ces outils au sein du système MCH, par exemple par des mises à jour logicielles téléchargeables par l'Internet ou depuis un support matériel de mise à jour.

En référence aux figures 2 et 3, le déroulement de l'encapsulation d'un contenu IMG en une bio-capsule BC peut être décrit plus particulièrement comme suit. En une étape El, le système MCH charge une image IMG des données numériques telles qu'elles existent dans le conteneur original matériel (support) ou logiciel (téléchargement) dont le contenu, ou objet, est à encapsuler. Le système MCH analyse E2 alors la structure de cette image IMG et en tire un certain nombre d'informations qu'il utilise pour identifier l'objet qu'elle représente. Ces informations peuvent être combinées avec des informations internes au système MCH, et sont utilisées pour référencer l'objet et sa bio-capsule au sein de la base de contenu DBC. Ce référencement peut comprendre en particulier, un type d'objet (musique, film, photos, etc), ainsi que divers champs en relation avec cet objet (catégorie, genre, sujet, auteur, acteurs, date, origine, etc.). Certaines de ces informations peuvent faire l'objet d'une requête auprès d'un serveur externe, par exemple un serveur CDDB pour obtenir l'intitulé des morceaux d'un CD de musique. Une bio-capsule BC issue de l'encapsulation des données IMG d'un objet comprend trois parties différentes, qui sont préparées en trois phases - 10 - E3, E4 et E5 avant d'être assemblées E7 sous la forme d'une bio-capsule entière. Certaines parties de ces phases peuvent être réalisées de façon indépendante, entre elles ou d'un module à l'autre. Une première partie PR de la bio-capsule BC, appelée prologue , comprend des informations s'attachant à l'objet en lui-même, ainsi qu'au site d'utilisation ou à son autorité d'utilisation AUT. Lors de l'encapsulation ENC d'un objet IMG, le système MCH prépare E31 le prologue PR en réunissant les données nécessaires à partir de l'analyse de l'image IMG chargée et possiblement en consultant diverses bases de données locales ou distantes pour compléter ces informations. Certaines informations peuvent aussi être saisies par un utilisateur représentant l'autorité d'utilisation AUT, à travers une interface utilisateur INTF comprenant une identification sécurisée de cet utilisateur. Une fois que l'ensemble des données à sécuriser du prologue PR sont réunies, le système calcule ou obtient E32 une signature numérique SgnO portant sur ce prologue et permettant de vérifier ultérieurement l'intégrité des données signées, par exemple par un algorithme asymétrique tel que RSA. Ce'le signature peut être calculée au sein du système MCH après validation par un utilisateur représentant l'autorisation d'utilisation AUT, à partir d'une clé locale CLL mémorisée dans le système ou générée ECL1. Lors d'une extraction ultérieure, cette signature SgnO permet alors au système de vérifier l'intégrité et la validité du prologue du point de vue de l'autorité d'utilisation, et de garantir qu'aucun utilisateur non autorisé n'en a modifié le contenu.

Cette signature peut aussi être calculée ou obtenue après validation auprès d'une autorité extérieure telle que l'autorité de contrôle ACTRL ou l'autorité de confiance ATRUST, par exemple par un appel du système MCH à un serveur sécurisé réalisant une authentification ECL2 à l'aide d'un certificat numérique, par exemple de type X509, alloué au site d'utilisation.

La clé locale CLL est alors livrée ECL3 ou validée par l'autorité extérieure après vérification de certaines conditions, par exemple l'authenticité ou l'intégrité du contenu, ou la validité des droits de l'autorité d'utilisation sur l'objet à encapsuler, ou la validité du contenu préparé pour être mémorisé dans le prologue PR. Lors d'une extraction ultérieure, cette signature SgnO - 11 - permet alors au système de vérifier l'intégrité et la validité du prologue du point de vue de l'autorité de contrôle ACTRL ou de confiance ATRUST, et de garantir que même l'autorité d'utilisation AUT n'en a pas modifié le contenu. Lorsque la clé locale CLL est livrée ou validée par une autorité extérieur, elle peut être mémorisée par le système MCH de façon temporaire et être utilisée pour plusieurs phases de l'opération d'encapsulation ENC, voire pour la totalité de l'opération. Il est ainsi possible de limiter le nombre d'appel ECL2 à l'autorité de contrôle ou de confiance, de façon à limiter les frais économiques, ainsi que les surcharges de travail ou les temps d'attente engendrés par ces appels. Le prologue PR comprend en particulier les données ou informations suivantes : GUID IT : donnée d'identification de l'objet encapsulé, appelée identifiant d'objet et généré selon un mode d'identification unique globale ( Global Unique IDentification ). Cette information est extraite des données numériques IMG à encapsulées, ou peut être obtenue auprès d'un serveur d'identification extérieur, par exemple un serveur CDDB, à partir de ces donné: s ni: nériques IMG ou d'une signature ou d'une donnée de résumé ( hash ) permettant leur identification.

GUID OW : donnée d'identification de l'autorité d'utilisation ou du site d'utilisation, appelée identifiant de site ou identifiant de propriétaire et généré selon un mode d'identification unique globale ( Global Unique IDentification ). Le terme de propriétaire doit ici s'entendre comme désignant le propriétaire dans le contexte d'utilisation. Cette information est mémorisée dans le système MCH ou obtenue auprès d'un serveur extérieur, par exemple l'autorité de contrôle ACTRL. DIDL : des informations catalogues caractérisant l'objet encapsulé, par exemple selon le standard DIDL ( Digital Item Description Langage ). Ces informations sont extraites des données numériques IMG à encapsulées, ou peuvent être obtenues auprès d'un serveur extérieur. A titre d'exemple pour un film, certains éléments compris dans ces informations de catalogue peuvent comprendre entre autres : - une icône représentant le film ; - le titre original du film -12- - une ou plusieurs langues utilisées dans la bande sonore, et les sous titres la durée du film les types d'outils de compression audiovisuels ( codecs ) utilisés - le format de l'image, et du son un avis portant su les catégories de public selon un ou plusieurs organismes (RACS, CEE, etc.) - différentes informations du générique du film - la date de réalisation les zones géographiques de commercialisation autorisées SgnO : donnée constituant une signature numérique portant sur l'ensemble des données du prologue PR, et garantissant l'intégrité de ce prologue et une autorisation d'une autorité pour la création de ce prologue PR ou de la bio-capsule BC à laquelle il appartient.

URICrypt : donnée constituant un identifiant universel de ressources ( Universal Ressource Identifier ) pointant vers et permettant l'accès à des ressources de cryptage ou décryptage. Typiquement un identifiant URI peut comprendre une d<v inée de type de protocole et un,' adresse de type URL ( Universal Ressource Locator ). L'accès à ces ressources est utilisé par le système MCH pour réaliser les divers traitements de cryptographie nécessaires pour encapsuler ou extraire le contenu IMG de la biocapsule BC. Ces ressources sont par exemple des outils logiciels mémorisés dans le système MCH et interfacés de façon interchangeable ( pluggable ) pour pouvoir être mis à jour sans modification importante du système. Ils peuvent aussi être accédés à la demande auprès d'un serveur extérieur, par exemple l'autorité de contrôle ACTRL ou de confiance ATRUST ou un prestataire de service spécialisé. IPM : données représentant un modèle de propriété intellectuelle ( Intellectual Property Model ) permettant de déterminer et gérer les droits de propriété intellectuelle attachés à l'objet encapsulé selon les conditions d'encapsulation ou d'utilisation de la bio-capsule. DIV : diverses informations portant sur I'encapsulation en elle-même, telle qu'une version de format d'encapsulation ou un sous-type de biocapsule. - 13 - Une deuxième partie CRACL de la bio-capsule BC, appelée crypto-ACL, est une version cryptée d'un groupe de données ACL appelé Liste de Contrôle d'Accès, et comprend des informations relatives aux différents utilisateurs répertoriés sur le site d'utilisation. Cette liste peut par exemple être implémentée sous la forme d'une structure de type XML ( eXtended Mark-up Langage ). Cette liste de contrôle d'accès ACL comprend en particulier les informations suivantes : Un groupe de tables PRU1 à PRU3 contenant chacune des informations constituant un profil pour un utilisateur potentiel déterminé U1 à U3. Chacune de ces tables comprend les informations suivantes : GUID U1 : donnée identifiant l'utilisateur U1 concerné, appelé identifiant utilisateur et généré selon un mode d'identification unique globale ( Global Unique IDentification ).

DU1 : données représentant les droits alloués à l'utilisateur concerné U1 par l'autorité d'utilisation AUT pour le contenu de la bio-capsule BC. MU1 : données représentant des informations biométriques de référence attachées à l'utilisateur in. concerné. Pour identifier ou authentifier un utilisateur, le système MCH lit des informations biométriques brutes en provenance de cet utilisateur par les moyens de lecture biométrique BIO et utilise un traitement de données biométriques pour les comparer aux informatiques biométriques de référence MU1 d'un ou plusieurs utilisateurs répertoriés. A titre d'exemple, les informations biométriques brutes lues par les moyens biométriques BIO peuvent être une image scannée d'une empreinte digitale. Or, pour un même utilisateur réalisant plusieurs lectures biométriques, les images scannées peuvent varier sensiblement d'une lecture à l'autre. Le traitement biométrique consiste alors à calculer une groupe de données, appelées minutiae MU1, représentant unensemble de points clés qui ressorte de ce traitement pour toutes les lectures d'un utilisateur, et pour aucune lecture d'aucun autre utilisateur. Ces minutiae constituent une caractéristique répétable et non ambiguë d'une personne physique et peuvent être utilisées pour identifier de façon certaine cette - 14 - personne, et ainsi authentifier son identité en tant qu'utilisateur du système MCH. Le système peut utiliser les minutiae d'un utilisateur U1 pour authentifier une demande comprenant déjà l'identité de cet utilisateur, de 5 façon alternative ou complémentaire à d'autres techniques comme le mot de passe. Le système peut aussi utiliser des informations brutes lues pour un utilisateur inconnu UT, et les traiter pour en tirer des minutiae à tester qui seront comparées aux minutiae connues, c'est à dire aux informations 10 biométriques de référence mémorisées, dans la bio-capsule BC demandée, pour les différents utilisateurs U1 à U3 déjà répertoriés. Le système peut ainsi réaliser une identification automatique et certaine de n'importe quel utilisateur répertorié effectuant une demande, sans que celui-ci ait besoin de décliner son identité. 15 URI BIO : donnée constituant un identifiant universel de ressources ( Universal Ressource Identifier ) pointant vers et permettant l'accès à des ressources logicielles de traitement biométrique. Ces ressources b;ométriques sont par exemple des outils logiciels mémorisés dans le système MCH et interfacés de façon interchangeable ( pluggable ) pour 20 pouvoir être mis à jour sans modification importante du système. Ils peuvent aussi être accédés à la demande auprès d'un serveur extérieur, par exemple l'autorité de contrôle ACTRL ou de confiance ATRUST ou un prestataire de service spécialisé. SgnUl : donnée constituant une signature numérique portant sur 25 l'ensemble des données du profil PRU1 de l'utilisateur concerné U1, et garantissant l'intégrité de ce profil ainsi qu'une autorisation d'une autorité pour la création de ce profil ou de la bio-capsule BC à laquelle il appartient. Lors d'une opération d'encapsulation ENC, le système réunit et/ou calcule E41 les différentes données devant constituer un ou plusieurs profils 30 PRU1 à PRU3 associés à un ou plusieurs utilisateurs U1 à U2 ou groupes d'utilisateurs. Une fois que l'ensemble des données à sécuriser d'un ou plusieurs profils PRU1 à PRU3 sont réunies, le système calcule ou obtient E42 une signature numérique SgnUl à SgnU3 portant sur chacun de ces profils et - 15 - permettant de vérifier ultérieurement l'intégrité des données signées, par exemple par un algorithme asymétrique tel que RSA. Chacune de ces signatures de profils est calculée au sein du système MCH de façon à ne correspondre qu'au seul profil utilisateur dont elle est issue. Ce calcul s'effectue à partir d'une clef fournie par une autorité validant le contenu de ce profil et qui peut être la même clef locale CLL que pour le calcul de la signature d'objet SgnO. Lors d'une extraction ultérieure, chacune de ces signatures SgnUl à SgnU3 permet alors au système vérifier l'intégrité et la validité du profil correspondant, du point de vue de l'autorité d'utilisation et possiblement d'une autorité extérieure ACTRL ou ATRUST, et de garantir qu'aucun utilisateur non autorisé n'en a modifié le contenu. Le système calcule E43 alors une clé utilisateur CRCLU1 à CRCLU3 correspondant de façon unique et non ambiguë à chacun des profils utilisateurs PRU1 à PRU3. Dans certaines variantes, cette clé utilisateur peut être directement issue de la signature du profil concerné, après autorisation d'une autorité, par exemple l'autorité d'utilisation AUT. Cependant, cette clé utilisateur peut avantageusement être calculée à partir c'i:ne part de la signature du profil de l'utilisateur concernée, et d'autre part d'une donnée constituant une clé d'image CLIMG, qui sera ultérieurement nécessaire pour décrypter les données numériques encapsulées dans la bio-capsule BC. Ce calcul utilise en outre une clé mémorisée dans le système ou fournie par une autorité, par exemple la clé locale CLL fournie ou validée par l'autorité d'utilisation et/ou par une autorité extérieure ACTRL ou ATRUST.

La clé d'image CLIMG peut être spécifique au contenu à encapsuler ou à une ou plusieurs catégories de contenus ou de bio-capsules. Cette clé est générée E40 ou reçue par le système, par exemple après validation par une autorité extérieure ACTRL ou ATRUST ayant délégation de la part d'un ayant-droits pour la propriété intellectuelle du contenu à encapsuler.

Plus particulièrement, chaque clé utilisateur CRCLU1 à CRCLU3 est obtenue par un cryptage de la clé d'image CLIMG. Ce cryptage est réalisé en utilisant une combinaison de la signature SgnUl à SgnU3 du profil correspondant et de la clé locale CLL, ou de façon à nécessiter cette combinaison pour pouvoir être décryptée. Chaque clé utilisateur constitue - 16 - ainsi une crypto-clé image, qui sera mémorisée dans la liste de contrôle d'accès ACL de la bio-capsule BC. De façon optionnelle, la clé utilisateur CRCLU1 peut aussi être utilisée pour décrypter une version cryptée CRCLIMG commune à plusieurs utilisateurs, de la clé d'image CLIMG.

Une fois que les différentes données de la liste de contrôle d'accès ACL sont calculées ou générées, le système les prépare E44 en un groupe de données qui sont alors cryptées E45 pour former la deuxième partie CRACL, ou crypto-ACL, de la bio-capsule BC en cours de préparation. Ce cryptage s'effectue à l'aide de la clé locale CLL, marquant ainsi l'approbation de l'autorité d'utilisation AUT et possiblement d'une autorité extérieure ACTRL ou ATRUST. Lors d'une demande d'extraction de cette bio-capsule BC par un utilisateur U1, il sera ainsi possible au système MCH de vérifier l'intégrité de cette bio-capsule et de n'accéder à la liste de contrôle d'accès ACL qu'avec toutes les autorisations nécessaires. A partir de cette liste de contrôle d'accès ACL, le système pourra alors réaliser une authentification voire une identification de l'utilisateur et vérifier la nature et l'authenticité de ses droits sur cett{: bio-capsule. Après ces vérifications d'accès, le système pourra alors obtenir clé d'image CLIMG par décryptage de la crypto-clé d'image CRCLU1 correspondant à l'utilisateur authentifié U1. Selon les besoins, par exemple le degré de sécurité recherché ou les conditions contractuelles, le système peut nécessiter expressément l'accord de l'autorité de contrôle ACTRL pour réaliser une encapsulation, tout en se satisfaisant de l'accord d'une autorité de confiance ATRUST pour l'extraction. L'autorité de contrôle n'a besoin d'intervenir alors qu'une seule fois par contenu, tandis que les extractions peuvent se contenter de l'accord d'une autorité de confiance, pouvant être plus spécialisée et plus économique et disposant de meilleures capacités ou horaires disponibilités. Une troisième partie CRIMG appelée crypto-image est une version cryptée de l'image IMG de l'objet encapsulé. Lors de l'encapsulation, cette crypto-image est obtenue par encryptage E51 de l'image IMG, en utilisant la clé d'image CLIMG. Avantageusement, l'ensemble des données formant le contenu est crypté directement à partir du format et de la structure qu'il présentent sur le - 17 - support matériel CDROM ou DVDROM ou à la réception COMM (fig.1), par exemple à partir d'une image de type ISO-9660 reçue ou lue sur un support matériel. Ainsi, l'encapsulation se fait de façon indépendante des possibles caractéristiques de contrôle ou de cryptage déjà prévues par l'éditeur ou le fournisseur du contenu à encapsuler. Par exemple, lors de l'encapsulation d'un contenu tel qu'un film sur DVD mémorisé sous la forme d'une image de type ISO-9660 contenant elle-même des données protégées par une protection de type Content Scrambling System (CSS), l'image ISO-9660 est cryptée telle quelle pour produire la crypto-image CRIMG. Lors de chaque extraction ultérieure de la bio-capsule BC ainsi obtenue, un décryptage de cette crypto-image CRIMG fournit des données de contenu qui sont à nouveau sous la forme de cette image ISO-9660. Les caractéristiques de protection telles que la protection CSS ne sont pas altérées par ces traitements d'encapsulation puis extraction, et peuvent donc rester actifs lors de l'exécution sur les moyens d'exécution ME sans gêner la gestion et le stockage par le système numérique MCH et dans la base de contenus DBC. Selon certaines variantes, certain profils utilisateurs de la liste de contrôle d'accès ACL peuvent correspondre à un groupe d'utilisateurs et comprendre par exemple des minutiae communes aux membre de ce groupe ou une pluralité de minutiae provenant des différents membres de ce groupe. Certains utilisateurs peuvent aussi donner ou recevoir une délégation totale ou partielle portant sur un tel profil d'utilisateur.

Dans une variante non représentée, une signature numérique commune peut aussi porter sur un ensemble de plusieurs profils utilisateurs. Chaque profil utilisateur peut alors contenir une donnée spécifique constituant une clé d'utilisateur, dont la valeur est alors authentifiée par la signature commune.

Dans une variante non représentée, une pluralité de listes de contrôle d'accès ACL correspondant à plusieurs objets différents peuvent être réunies voir fusionnées au sein d'une base de données commune à toute une librairie d'objets gérés par le système MCH de gestion de contenus, par exemple une base de données incluant la base de contenu DBC. - 18 - Pour une telle bio-capsule BC, la figure 4 illustre l'extraction de l'image IMG qu'elle contient, par exemple une image ISO-9660. Pour exécuter un objet IT choisi 40 dans la base de contenus DBC par un utilisateur U1, le système lit ou reçoit la bio-capsule BC contenant l'image IMG correspondant à cet objet IT, et charge 41 cette bio-capsule dans un module d'extraction EXTR. Au sein de la bio-capsule, le système repère le prologue PR, et en analyse 42 les différents champs de données. A partir des données du prologue, le système identifie l'objet (GUID IT) encapsulé et l'autorité d'utilisation ou le propriétaire dans le contexte (GUID OW). A partir de la signature d'objet SgnO lue dans le prologue, le système réalise alors une authentification 43 du prologue, par exemple à l'aide d'une clé locale CLL mémorisée sur le site d'utilisation. Dans un mode de réalisation utilisant une autorité extérieure ACTRL ou ATRUST, le système entre en communication avec cette autorité pour lui faire identifier l'objet IT et/ou authentifier le prologue PR. L'autorité extérieure peut aussi vérifier l'identité de l'autorité d'utilisation ou du site d'utilisation, ainsi que diverses conditions contractuelles, par exerrmplc: en relation avec un abonnement ou avec le modèle de propriété intellectuelle IPM lue dans le prologue. Cette authentification peut par exemple se faire par un certificat numérique (par exemple de type X509) acquis auprès d'une société spécialisée telle que la société Verisign. Si l'autorité extérieure valide le prologue et la demande de l'utilisateur U1, c'est alors elle qui fait alors parvenir au système la clé locale CLL. Selon les variantes, cette clé locale CLL peut rester la même pour toutes les opérations d'authentification et/ou de décryptage au cours de l'extraction, ou peut être demandée et renouvelée chaque fois il en est besoin. Si les conditions d'autorisation et d'authentification sont réunies, le système décrypte 44 alors la crypto-ACL CRACL de la bio-capsule, par exemple à l'aide de la clé locale CLL. Ce décryptage s'effectue en utilisant des outils de décryptage auxquels le système accède grâce à l'adresse URI CRYPT mémorisée dans le prologue PR. A partir de la liste de contrôle d'accès ACL ainsi obtenue, le système réalise un certain nombre d'opérations 45 à 48 dont l'ordre peut varier. - 19 - A partir des minutiae biométriques MU1 lues dans les différents profils utilisateurs PRU1 à PRU3 de la liste de contrôle d'accès ACL, le système identifie 45 l'utilisateur U1 ayant demandé l'extraction, ou authentifie cet utilisateur si son identité lui est déjà connue.

A partir des droits d'accès DU1 lus dans les différents profils utilisateurs, le système vérifie 46 que l'utilisateur U1 ayant demandé l'extraction dispose bien de droits d'accès DU1 compatibles avec cette demande. A partir de la signature numérique SgnUl mémorisée avec le profil utilisateur PRU1 de l'utilisateur U1 ayant demandé l'extraction, le système vérifie 47 que ce profil utilisateur n'a pas été modifié depuis la création ou la dernière mise à jour autorisée de la bio-capsule BC. Selon certaines variantes, cette vérification peut utiliser la clé locale CLL. En utilisant la clé locale marquant l'approbation de l'autorité d'utilisation et possiblement de l'autorité extérieure, le système décrypte 48 la clé utilisateur CRCLU1 mémorisée avec le profil utilisateur PRU1 authentifié de façon à obtenir la clé image CLIMG correspondant au contenu IMG encapsulé. Lorsque ces opérations 45 à 48 sont réalisées de façon satisfaisante, le système utilise la clé image CLIMG précédemment obtenue pour décrypter 49 la crypto-image CRIMG, de façon à obtenir l'image IMG du contenu qui a été encapsulé dans la bio-capsule BC. Le système peut alors transmettre cette image aux moyens d'exécution pour en jouer le contenu. Si cette image IMG contient elle- même des caractéristiques spécifiques ou de protection, le système ou les moyens d'exécution ME en eux-mêmes effectue les opérations prévues par ces caractéristiques de la même façon que si l'image IMG était directement issue d'un fichier reçu ou lu sur support matériel. Ainsi qu'illustré en figure 5, l'invention peut être utilisée dans un site d'utilisation constitué par exemple d'un logement pouvant comprendre plusieurs pièces L1 à L4 disposant de multiples moyens d'exécution ME1 à ME4 et/ou d'identification biométriques B1 à B5. L'utilisation de bio-capsules selon l'invention permet alors en particulier de réaliser une gestion souple et performantes de contenus, par exemple des contenus multimédia, sans -dégrader le niveau de protection ou les caractéristiques spécifiques d'organisation entourant ses contenus. Ainsi qu'illustré en figure 6, l'invention peut aussi être utilisée dans un site d'utilisation recevant des clients dans plusieurs locaux CHO à CH5, par exemple un hôtel ou un groupe de salles de spectacles individualisées. L'utilisation de bio-capsules selon l'invention permet alors en outre de réaliser un suivi des contenus utilisés, pouvant être lié à une facturation sur mesure ou à un suivi fournissant des informations sur les choix des clients. Ainsi qu'illustré pour le local CH5, l'invention peut aussi permettre de fournir à un utilisateur des contenus de type logiciel, par exemple des applications bureautiques ou des jeux vidéos. Ces contenus logiciels sont encapsulés dans des bio-capsules selon l'invention, et l'image IMG qui en est extraite est alors transmise à des moyens de traitement de données MD5, par exemple un ordinateur ou une console de jeu.

Les différents procédés de cryptage ou décryptage cités dans la présente description le sont à titre d'exemple, et peuvent varier selon les modes de réalisation, par exemple en fonction des matériels et algorithmes disponibles et de leurs performances en matière de vitesse de travail ou de solidité de protection. Les algorithmes de type symétrique, tels que DES, sont en général plus rapides que ceux de type asymétrique tels que RSA. Pour cette raison, ils peuvent être intéressants à utiliser pour le cryptage de gros volumes, par exemple le cryptage et décryptage des données formant l'image IMG de l'objet encapsulé. Il est toutefois aussi envisageable d'utiliser pour le même cryptage des algorithmes asymétriques pour plus de sécurité ou de souplesse, même lorsque toutes leurs fonctionnalités de paires de clés (privée et publique) ne sont pas pleinement utilisées. Le système de gestion des contenus peut être géré par divers types de logiciels d'exploitation, tels que Linux ou Windows de la société Microsoft ou MacOS de la société Apple. Le ou les fichiers contenant les différentes éléments de la bio-capsule décrite ici peut bien sûr varier selon le système d'exploitation utilisé, et selon la façon dont est implémenté les différents procédés décrits ici. La structure décrite ici pour une bio-capsule est donc à prendre au sens d'une structure logique, et l'ordre de mémorisation des - 21 - données y a moins d'importance que le mode d'obtention de ces données et la natures des informations qu'elles représentent. Par exemple, dans le cas d'un système d'exploitation de type Windows XP, certaines données seront mémorisées sous la forme d'un fichier NTFS classique tel que géré par le logiciel système en version standard, et d'autres données seront mémorisées sous la forme d'un objet associé de type NTFS stream associé au fichier NTFS classique au sens de Windows XP. Ainsi pour un objet de type film sur DVDROM, un fichier NTFS classique, par exemple d'extension .DVD , pourra contenir l'image cryptée CRIMG et les données contenant les méta-données de type DIDL ainsi qu'une identification du film au format IDv4DVD. Un élément associé de type stream NTFS pourra alors contenir des données plus spécifiques à la bio-capsule. Il pourra s'agir en particulier des éléments de la Liste de Contrôle d'Accès tels la signature d'authentification de l'objet par l'autorité de contrôle, des informations biométriques de références, des références et particularités de fournisseurs de différents outils, et d'une adresse d'accès à l'autorité d?. contrôle ACTRL ou de confiance ATRUET. L'ensemble des objets logiciels correspondant à une même bio- capsule peut ainsi être manipulé ensemble, par exemple directement à partir de l'interface logicielle du système d'exploitation (Explorateur Windows, etc.), ou bien à travers le moteur d'indexation standard de Windows XP, ou à travers les API standard de Windows XP utilisées pour la programmation d'un logiciel gérant ces bio-capsules. Au sein de Windows XP, il est aussi possible d'ajouter un composant spécifique de type IFilter programmé pour lire les données mémorisées dans les différents objets logiciels (fichier NTFS et stream NTFS) constituant la bio-capsule, de façon à permettre une visualisation explicite, directement sous Windows XP, des données constituant le prologue et/ou la liste de contrôle d'accès de la bio-capsule. Bien sûr, l'invention n'est pas limitée aux exemples qui viennent d'être décrits et de nombreux aménagements peuvent être apportés à ces exemples sans sortir du cadre de l'invention.

Claims (19)

REVENDICATIONS

1. Procédé pour encapsuler des données numériques contenues dans un conteneur original (IMG) et destinées à être exploitées à partir d'un support matériel de données numériques (DBC) par un ou plusieurs utilisateurs physiques (U1) prédéterminés auxquels des droits d'accès ou d'exploitation sont attribués, ce procédé comprenant : - une génération d'une clef d'utilisateur associée à chaque utilisateur de façon unique ; -une réalisation d'une bio-capsule (BC) comprenant : • une première partie (PR) comprenant des informations descriptives des données, ^ une deuxième partie (ACL, CRACL) signée ou cryptée contenant les droits d'accès (DU1) conférés à chaque utilisateur et des informations de référence (MU1) identifiant ou authentifiant lesdits utilisateurs, et • une troisième partie (CRIMG) comprenait un conteneur virtuel crypté, dérivé d'une image du conteneur original (IMG) ; et - un stockage de ladite bio-capsule (BC) sur le support matériel de données numériques (DBC).

2. Procédé selon la revendication 1, caractérisé en ce que la première partie (PR) comprend en outre des informations (IPM) descriptives de droits de propriété intellectuelle associés aux données numériques du conteneur original (IMG).

3. Procédé selon l'une des revendications 1 ou 2, caractérisé en ce que la bio-capsule (BC) est stockée au sein d'un système (MCH) gérant une pluralité de telles bio-capsules.

4. Procédé selon l'une des revendications 1 à 3, caractérisé en ce que la première partie (PR) comprend en outre une signature numérique dite d'objet (sgnO) portant sur tout ou partie de la bio-capsule (BC).- 23 -

5. Procédé selon l'une des revendications 1 à 4, caractérisé en ce que la deuxième partie (CRACL) est cryptée (E45) de façon à nécessiter (43) la signature d'objet (sgnO) pour son décryptage (44).

6. Procédé selon l'une des revendications 1 à 5, caractérisé en ce que la deuxième partie (CRACL) comprend au moins une crypto-clef d'image (CRCLU1, CRCLIMG), elle-même cryptée (E43) à partir d'une clef d'image (CLIMG) nécessaire pour décrypter (49) le conteneur virtuel (CRIMG) contenant l'image du conteneur original (IMG).

7. Procédé selon l'une des revendications 1 à 6, caractérisé en ce que la clef d'image (CLIMG) dépend d'une part d'informations liées au conteneur original ou aux données qu'il contient (IMG) et d'autre part d'informations dépendant des conditions de réalisation de la bio-capsule (BC).

8. Procédé selon l'une des revendications 6 ou 7, caractérisé en ce que la crypto-clef d'image (CRCLIMG) est cryptée de façon nécessiter au, m-)ins une clef d'utilisateur (CRCLU1) pour être décryptée.

9. Procédé selon l'une des revendications 6 à 8, caractérisé en ce que la clef d'utilisateur (CRCLUI) est générée à partir d'informations biométriques de référence (MU1) identifiant au moins un utilisateur (U1) disposant des droits adéquats, lesdites informations biométriques étant comprises dans les informations de référence mémorisées dans la bio-capsule (BC) pour ledit utilisateur.

10. Procédé selon l'une des revendications 1 à 9, caractérisé en ce que la deuxième partie (CRCAL) comprend au moins une signature numérique dite d'utilisateur (sgnUI) délivrée par une autorité d'utilisation (AUT) et portant sur tout ou partie des droits conférés à au moins un utilisateur (U1).

11. Procédé selon la revendication 10, caractérisé en ce que la deuxième partie (CRCAL) comprend au moins deux profils d'utilisateurs (PRU1 à- 24 -PRU3) décrivant des droits d'accès différents et comprenant chacune une signature numérique d'utilisateur (sgnUl à sgnU3).

12. Procédé selon l'une des revendications 10 ou 11, caractérisé en ce qu'au moins une clef utilisateur (CRCLUI) est générée à partir d'une signature numérique d'utilisateur (sgnUl).

13. Procédé selon l'une des revendications 1 à 12, caractérisé en ce qu'il comprend en outre une étape de validation (ECL2) conditionnant la réalisation de la bio-capsule (BC), cette validation étant réalisée auprès d'au moins une autorité dite de contrôle (ACTRL) et à partir d'une identification ou d'une authentification (ECL4) du conteneur original ou des données numériques qu'il contient (IMG).

14. Procédé selon l'une des revendications 1 à 13, caractérisé en ce qu'il comprend en outre une étape de validation conditionnant la réalisation de la bio-capsule, cette validation étant réalisée auprès d'au moins une autorité dite de contrôle et partir d'une identification ou d'une authentification de l'autorité d'utilisation (AUT) ou d'au moins un utilisateur autorisé par ladite autorité d'utilisation.

15. Procédé selon l'une des revendications 1 à 14, caractérisé en ce que la bio-capsule (BC) est réalisée de façon à ce que le décryptage (44) de la deuxième partie (CRACL) nécessite une validation par au moins une autorité de contrôle (ACTRL, ATRUST).

16. Procédé selon l'une des revendications 1 à 15, caractérisé en ce qu'il s'applique à un conteneur original (IMG) contenant lui-même les données numériques sous une forme cryptée.

17. Procédé selon l'une des revendications 1 à 16, caractérisé en ce qu'il utilise au moins une donnée d'identification de ressource (URICRYPT) permettant l'utilisation d'une ressource de cryptage ou décryptage (OC) accessible auprès d'une bibliothèque ou d'un serveur de ressources (IOUT).30- 25 -

18. Procédé selon l'une des revendications 1 à 17, caractérisé en ce qu'il utilise au moins une donnée d'identification de ressource (URIBIO) permettant l'utilisation d'une ressource d'identification ou d'authentification biométrique (OB) accessible auprès d'une bibliothèque ou d'un serveur de ressources (IOUT).

19. Système pour encapsuler des données numériques contenues dans un conteneur original (IMG) et destinées à être exploitées à partir d'un support matériel de données numériques (DBC) par un ou plusieurs utilisateurs physiques (U1) prédéterminés auxquels des droits d'accès ou d'exploitation sont attribués, ce système comprenant : - des moyens pour générer une clef unique (CRCLUI) associée à chaque utilisateur (U1) ; des moyens pour réaliser une bio-capsule comprenant : ^ une première partie (PR) comprenant des informations descriptives des données, • une deuxième partie (ACL, CRCAL) i'ignée ou cryptée contenant les droits d'accès (DU1) conférés à chaque utilisateur et des informations de référence (Mn) identifiant ou authentifiant lesdits utilisateurs, et ^ une troisième partie (CRIMG) comprenant un conteneur virtuel crypté, dérivé d'une image du conteneur original (IMG) ; et - des moyens pour stocker ladite bio-capsule (BC) sur le support matériel 25 de données numériques (DBC). 25. Système selon la revendication 19, caractérisé en ce que les moyens de réalisation d'une bio-capsule (BC) sont agencés pour opérer à partir d'un conteneur original (IMG) lu sur un support matériel (DVDROM, CDROM, K7, 30 COMP) ou reçu par des moyens de communication (COMM). 26. Système selon l'une des revendications 19 ou 20, caractérisé en ce qu'il comprend en outre des moyens de traitement de données agencés pour décrypter et exploiter les données numériques d'une bio-capsule (BC).2026 - 22. Système selon la revendication 21, caractérisé en ce que les moyens de traitement sont agencés pour conditionner le décryptage de la clef d'image (CLIMG), à partir d'au moins une crypto-clef d'image (CRCLU1, CRCLIMG), à une identification ou une authentification d'au moins un utilisateur (U1) disposant des droits adéquats, réalisée à partir d'informations de référence comprenant des informations biométriques de référence (MU1) mémorisées dans la bio-capsule (BC) et correspondant audit utilisateur.