Brevet FR2823936A1 — publié le 20021025

lecture (PAL) PROCEDE ET SYSTEME D'ACCES CONDITIONNEL A DES SERVICES IP DOMAINE TECHNIQUE La présente invention se situe dans le domaine de l'embrouillage et du contrôle d'accès à des services IP. L' invention concerne plus particulièrement un procédé et un système d'émission/réception d'informations avec contrôle d'accès à travers un réseau utilisant le protocole IP ainsi qu'un dispositif permettant de mettre en _uvre le procédé. Ce procédé peut être utilisé pour contrôler l'accès aux services de flux audiovisuel sur IP et aux services de diffusion de données diffusés par satellite à travers l'internet. ETAT DE LA TECHNIQUE ANTERIEURE Plusieurs solutions sont actuellement utilisées pour réaliser l'embrouillage et le contrôle d'accès sur des données IP. Parmi ces solutions, citons le standard IPSEC qui permet de transporter de façon confidentielle des données dans des datagrammes IP en mode point à point. Ce standard offre les services suivants: - confidentialité - authentification. - intégrité. La protection IPSEC ne nocessite pas la modification du serveur ou des logiciels applicatifs installés chez le client. Cependant, l'embrouillage est SR19013 HM généralement appliqué à 1'ensemble du trafic entre le client et le serveur et pas seulement à un service spécifique. Aussi, dans la mesure o le trafic comporte des données qui ne nocessitent pas de protection, le standard IPSEC ne peut pas être utilisé si l'on souhaite réaliser un embrouillage sélectif sur des services déterminés. Un autre inconvénient de ce standard provient du fait qu'il impose l' existence d'une voie de retour. Or, dans le cadre d'une application pointmultipoint, la voie de retour n'est pas nocessaire, par exemple transmission par satellite (multicast en anglais). Par ailleurs, l'échange des clés permettant daccéder aux contenus s'effectue par le blais de l'utilisation d'algorithmes à clé publique. De ce fait, ce standard ne permet pas de conditionner l'accès au contenu de l' information moyennant la possession de droits tels que ceux définis pour la télévision numérique par exemple (pay per view, abonnement, etc... .) et qui sont inscrits dans un processeur de séaurité. Citons également le standard SSL (Seaure Socket Layer en anglais) qui est une technique de chiffrement appliquée aux données au niveau de la couche de transport. Cette technique utilise des identificateurs de protocole et des numéros de ports pour distinguer les données protogées des données non protégées. Par exemple, un lien hypertexte sur le réseau utilisera cette technique si l'identificateur de protocole indique "HTTPS" au lieu de "HTTP". Les données protogées par SSL naviguent généralement à travers une connexion au port 443 du serveur TCP. Aussi, si le SR19013 HM serveur reçoit une connexion au port 443, il applique lembrouillage SSL à cette connexion et transmet les donnces IP au client. Cette procédure permet au client et au serveur de distinguer les données protogées de celles qui ne le sont pas. Un inconvénient de cette technique provient de sa dépendance du protocole de transport TCP utilisé et impose de ce fait le format de donnces de ce protocole aux données à embrouiller. Le but de l' invention est de remédier aux inconvénients de l'art antérieur décrits ci-dessus au moyen d'un procédé permettant d'embrouiller des services IP de façon générique et de contrôler l'accès à ces services au moyen d'un dispositif de contrôle d'accès tel qu'une carte à mémoire. Un autre but de l' invention est de s'affranchir des contraintes liées au protocole de transport. Un autre but est de réaliser un embrouillage de données IP quelle que soit l 'application utilisant ces données, notamment dans les configurations de service suivant: - Services "point à point"; - Services multipoint avec existence d'une voie de retour " client serveur "; - Services multipoint sans voie de retour " client serveur ". Ces buts sont atteints au moyen d'un procédé comportant les étapes suivantes: A l'émission: - Embrouiller un premier datagramme IP; SR19013 HM - Définir un entête comportant au moins une donnée identifiant les moyens de contrôle d'accès; - Concaténer cet entête avec le premier datagramme embrouillé pour créer un bloc de données; - Encapsuler le bloc de données dans un deuxième datagramme IP; - Emettre ce deuxTème datagramme IP à travers le réssau; et A la réception: - extraire le bloc de données du datagramme requ; - extraire l'entête; - désembrouiller le premier datagramme si l'accès à ces donnces est autorisé; - délivrer les données désembrouillées. Selon l' invention, le bloc de données est encapeulé dans un paquet UDP. Selon l'invention, le bloc de données est encapsulé directement dans un datagramme IP. Selon l'invention, l'étape d'embrouillage comporte les phases suivantes: Définir les services à embrouiller par un label auquel correspond une adresse IP source ou une adresse IP destination; - Saisir au moins une condition d'accès ou au moins une clé secrète. Selon l' invention, le bloc de donnces comporte: - l'entête (Access_control_header) véhiculant les informations nocessaires au traitement par un terminal utilisateur des données transportées; et - Une séquence (Payload) représentant les informations à embrouiller. SR19013 HM Selon l'invention, le bloc de donnces respecte la syntaxe suivante: CAS_DATA_UNIT() { Access_control_header() p octets Payload q octets Selon l' invention, la séquence (Payload) respecte la syntaxe suivante: payload() { data bytes n octets padding bytes p octets, (p pouvant prendre la valeur O) } L'entête comporte en outre un champ (EDC) représentant une séquence de détection d'erreurs. Selon un mode de réalisation de l' invention, dans lequel le bloc de données est inséré dans un paquet UDP, qui est lui même inséré dans un datagramme IP, en émission, un port UDP source est alloué dynamiquement à l'ouverture du lien UDP. Dans ce mode de réalisation, l'attribution du numéro de port UDP de destination peut être réalisée de façon statique (données de configuration éventuelle dédice par une autorité de réqulation) ou bien dynamiquement par un protocole de signalisation entre ltembrouilleur et le désembrouilleur. Selon ce mode de réalisation de l'invention, la réception des datagrammes IP/UDP par le client final comporte les étapes suivantes: - recevoir le deuxTème datagramme IP; BR19013 HM - recevoir le paquet UDP sur le port, précédemment ouvert (port statique ou dynamique); - récupérer et désembrouiller le bloc de données; extraire l'entête; - envoyer le datagramme IP désembrouillé à un pseuJodriver; - Extraire les données du premier datagramme Destination; envoyer le paquet extrait à l'application destination. Selon une alternative dans ce mode de réalisation, la réception des datagrammes UDP par le client final comporte les étapes suivantes: recevoir le deuxième datagramme IP; - recevoir le paquet UDP sur le port ouvert (port statique ou dynamique); - récupérer et désembrouiller le bloc de données; - extraire l'entête; - ré-émettre le premier datagramme IP sur l'adresse loophack de la pile IP; - extraire les données du premier datagramme et les envoyer à l'application destinataire. Selon l' invention, les services IP transmis sont des flux audiovisuels sur IP. Selon l'invention, les services IP transmis sont des donnces transmises par satellite via un réseau IP. Les données sont émises à travers un réscau IP par un émetteur comportant des moyens pour associer aux datagrammes IP un entête comprenant au moins une donnée identifiant les moyens de contrôle d'accès et une indication de la méthode d'embrouillage utilisée. SR19013 HM L'émetteur selon l' invention comporte en outre: - des moyens pour définir les services à embrouiller par un label auquel correspond une adresse IP source ou une adresse IP destination; - des moyens pour saisir au moins une condition d'accès ou au moins une clé secrète. Selon l' invention, cet émetteur comporte un serveur de flux de données IP, une passerelle comportant un embrouilleur IP, un générateur d'ECM, un générateur d'EMM et une base de donnces. La réception des données émises à travers le réseau est réalisée par un récepteur comportant des moyens pour extraire l'entête d'un datagramme embrouillé et des moyens pour activer au moins une condition d'accès ou au moins une clé secrète. Le système d' embrouillage et de contrôle d' accès dans un réseau de type IP comporte un émetteur et un récepteur tels que décrit ci-dessus. Le Dispositif d'embrouillage et de contrôle d'accès de services IP selon l 'invention comporte une interface homme-machine destince à définir les services à embrouiller et à saisir les conditions d'accès ou des clés secrètes. Selon l'invention, les moyens de contrôle d'accès comportent une carte à mémoire pour le transport de la clé secrète. BREVE DESCRIPTION DES FIGURES D'autres caractéristiques et avantages de l' invention ressortiront de la description qui va SR19013 HM i suivre, prise à titre d'exemple non limitatif, en référence aux figures annexées dans lesquelles: - la figure 1 représente schématiquement un système d'émission/réception de données avec contrôle d'accès selon l' invention; - la figure 2 illustre schématiquement les étapes de définition de la structure d'un datagramme selon l' invention; - la figure 3 illustre schématiquement un mode préféré de réalisation de l'embrouillage selon l' invention; - la figure 4 illustre schématiquement un premier mode de réception mis en _uvre dans le procédé selon l' invention; - la figure 5 illustre schématiquement un deuxième mode de réception mis en _uvre dans le procédé selon l' invention; - la figure 6 représente schématiquement un système d'embrouillage de données dans un environnement point-à-point selon l' invention. DESCRIPTION DETAILLEE DE MODES DE MISE EN OEUVRE DE L' INVENTION La figure 1, illustre schématiquement un système dans lequel plusieurs équipements de traitement et d'émission de données sont interconnsctés dans un réseau local 2 (LAN, Local Area Network en anglais) qui est relié, via le réseau internet 3, à plusieurs clients 4. Le LAN 2 comporte un serveur 6 de flux de données IP, une passerelle 8 comportant un embrouilleur IP, un générateur d'ECM 12 (message de contrôle d'accès DVB, EntiLlement Control Message en anglais), un générateur d'EMM 14 (message de gestion d'accès DVB, Entitlement Management Message en anglais) et une base de données 16. Le LAN 2 est connecté à un serveur Web 17. Le serveur WEB 17 indiquant les caractéristiques du serveur Application (@IP_serveur, nom programme, embrouillage_actif) n'est pas nécessairement sur le même LAN 2. Les données IP délivrées par le serveur de flux 6 peuvent être des services audio visuels nocessitant la possession d'un droit d'accès enregistré dans une carte à mémoire détenue par les clients 4 autorisés. Ces services audio visuels sont embrouillés par l'embrouilleur IP intogré à la passerelle 8 avant d'être transmis à travers le réscau internet 3. Chaque client 4 dispose d'un équipement 18 comportant un dispositif de contrôle d'accès tel que par exemple une carte à mémoire. La passerelle 8 est dotée d'un programme d' interface homme-machine IHM lui permettant: - de définir les services à embrouiller; - de saisir des conditions d'accès ou des clés secrètes. Les services à embrouiller sont identifiés par un label auquel correspond une adresse IP source ou une adresse IP destination suivant que l'on souhaite embrouiller les données provenant d'une source et/ou allant vers une destination. SR19013 HM Comme cela est illustré par les tableaux ci- dessous (tableau I et II), l'embrouillage des données résulte de la mise en relation de l'identificateur du service (Idservice), caractérisé par l'adresse source (s) et/ou destination (d) des datagrammes IP, et d'une clé d'embrouillage. La périodicité de renouvellement de cette clé est relativement faible dans les systèmes ntutilisant pas de carte à mémoire (tableau I), et peut être plus élevée dans les systèmes mettant en _uvre une carte (tableau II). Dans ces derniers, elle porte le nom de mot de contrôle. TABLEAU I Adresse à filtrer Origine Clé Id service et embrouiller (source d'embrouillage ou dest.) Service p format IPVX S et/ou D TABLEAU II Label Adresse à filtrer Origine(source Mot de Conditions et embrouiller ou dest.) contrôle d'accès Service au format IP VX S et/ou D CA i Dans les systèmes mettant en _uvre une carte à mémoire, l'obtention du mot de contrôle est soumise à la possession de droits préalablement inscrits dans la carte. La signalétique liée à la mise en _uvre du système de contrôle d'accès utilisant la carte à mémoire pour restituer les mots de contrôle dans le contexte IP couvre par ordre de priorités les services suivants: SR19013 HM - services de diffusion de données utilisant la pile UDP/IP: IPSat (push, transfert de fichiers); - services de diffusion audiovisuelle sur IP (IP flux multipoint) utilisant la pile UDP/IP (visioconférence ou audioconférence multipoint, diffusion audiovisuelle); - services de consultation audiovisuelle sur IP utilisant la pile UDP/IP (VOD, visioconférence point à point, téléphonie sur IP); - services transactionnels utilisant la pile TCP/IP. La figure 2 illustre schématiquement les étapes de création d'un datagramme selon l' invention. Les données à transmettre 20 sont d'abord découpées en paquet 21 qui peuvent être de longueurs variables. Chaque paquet 21 est ensuite associé à un entête IP 22 pour constituer un premier datagramme IP 23. La transmission des paquets 21 à travers le réscau IP repose sur le principe suivant: - Embrouillage du premier datagramme IP 23 (PDU, Protocole Data Unit en anglais). - définition dun entête 24 "access_control_header" appelé "signalétique de contrôle d'accès" permettant de fournir au désembrouilleur les éléments intervenus dans l'opération d'embrouillage. Cet entête 24 comporte un discriminateur 25 identifiant le type de système de contrôle d'accès mis en _uvre pour embrouiller le datagramme IP 23, et des données de contrôle 27. - Concaténation de cet entête 24 et du datagramme IP 23 pour former un bloc de données 26; SR19013 HM i - Encapsuler ce bloc de données 26 dans un datagramme UDP. L'ensemble de ces opérations est appelé IP-CAS (IP- Conditionnel Access System) dans la suite de la description. La structure générale d'un entête 24 est illustrée dans l'annexe 1 décrivant les différents champs représentent des blocs de données binaires. Cet entête 24 comporte: - un champ (header_length) représentant la longueur totale de l'entête 24; - un champ (payload_scrambling_control) indiquant le mode d' application de l'embrouillage en cas d'embrouillage des informations utiles. L'entête 24 peut comporter également un champ ( EDC) représentant une séquence de détection d'erreurs. Selon ltinvention, si (payload_scrambling_control-OO), l'entête 24 (Access_control_header) comporte en outre un champ (payload_descrambling_way) précisant le mode de désembrouillage du contenu de la charge utile. Si le champ (payload_descrambling_way = xi), xi étant une valeur binaire, l'entête 24 comporte en outre un champ (ECM_CA_descriptor_flag) indiquant la présence d'au moins un descripteur d'accès conditionnel ( ECM_ CA_descriptor) dans l'entête 24 du datagramme embrouillé 23, et un champ ( ECM_ flag) indiquant, lorsque sa valeur est égale à 1, la présence d'au moins un champ ECM() dans l'entête du datagramme embrouillé 23. Si (ECM_CA_descriptor_flag=1), l'entête 24 comporte un champ (Nb_ ECM_ CA_descriptor) indiquant le nombre de blocs (ECM_CA_descriptor) présents dans cet entête 24 du datagramme embrouillé 23. L'entête 24 comporte également un champ (access_control_header_start_sequence) ou permettant d' identifier le début de l'entête, un champ (version_number) indiquant la version courante de l'entête 24, un champ (service_ID) indiquant la référence du service utilisé, un champ (payload_type) indiquant le type de données transmises, et un champ (RUF0) réservé pour un usage futur. L'entête 24 comporte par ailleurs un champ (scrambling_algorithm_type) destiné à indiquer le type d'algorithme utilisé pour embrouiller le datagramme, et un champ correcteur d'erreur (CRC_32) des données utiles désembrouillées. Si le datagramme 23 est embrouillé par un algorithme fonctionnant dans le mode bloc, l'entête 24 (Access_control_header) comporte en outre: - un champ (payload_padding_size) précisant le nombre d' octets de bourrage rajoutés en fin de la charge utile; - un champ (IVOperator_ ID_ length) indiquant, lorsque sa valeur est différente de zéro, la présence et la longueur du champ vecteur d'initialisation de l'embrouilleur; - un champ (IVOperator_ ID_ value) indiquant, lorsque la valeur de (IVOperator-IDlengCh) est différente de zéro, la valeur du vecteur d'initialisation de l'embrouilleur, et - un champ (RUF1) réservé pour un usage futur. SR19013 HM L'entête 24 comporte en outre un champ (ECM_CA_descriptor_flag) indiquant, quand sa valeur est égale à 1, la présence d'au moins un descripteur daccès conditionnel (ECM_CA_descriptor) dans l'entête 24 du datagramme embrouillé 23, un champ (RUF2) réservé pour un usage futur. L'entête 24 comporte également un champ (ECM_CA_descriptor_version_number) indiquant la version du bloc (ECM_CA_descriptor). Si (EMM_CA_descriptor_flag = 1), l'entête 24 comporte un champ (EMM_CA_descriptor_version_number) indiquant la version du bloc (EMM_CA_descriptor) et un bloc de donnces (EMM-CA desriptor). Si (ECM_flag = 1), l'entête 24 comporte un champ (NB_ECM) indiquant le nombre d'ECM dans l'entête 24 du datagramme embrouillé 23. Si (payload_descrambling_way=010), l'entête 24 comporte un troisième champ (RUF3) réservé pour un usage futur; Le message de contrôle d'accès comporte: - un pointeur ECM_index destiné à différentier plusieurs ECM pour sélectionner un ECM particulier pour le désembrouillage; - une table ECM_table contenant les données de l'ECM et les instructions de changement de phase. A titre d'exemple, le message de contrôle d'accès présente le format suivant: ECM() { ECM_index 8 bits ECM_table() 8 bits } SR19013 HM o ECM_ index représente l' ECM associé au descripteur d'accès conditionnel, et ECM_ table(), représente la structure des ECM. La table ECM comporte: - un champ d' identification (table_id) - un champ indiquant la longueur d'un ECM, (ECM- lengCh) ECM_ table(), présente la structure suivante: ECM_ table(){ table_id = 0x80 ou Ox81 8 bits NOT_USED. 4 bits ECM_l engCh 12 bits NOT_USED 8 bits For (i = 0; i - un pointeur (ECM_ index). A titre d'exemple, le descripteur d'accès conditionnel (ECM_ CA_descriptor) présente le format suivant: ECM_ CA_descriptor(){ SR19013 HM Descriptor_tag = 0x09 8 bits ECM_CA_descriptor_lengCh 8 bits CA_system_ID 16 bits ECM_index 8 bits for (i = 0; i l'identificateur CI-tag. L'identificateur du type d'algorithme d'embrouillage présente le format suivant: CI(){ CI_tag= 0x13 8 bits CI_lengCh=0x01 8 bits CI_value 8 bits } L'opérateur du service comporte: - un identificateur SOID_tag du bloc permettant de décrire la zone de l'opérateur de service utilisé dans la carte à puce; - un champ SOID_lengCh indiquant la longueur de ladite zone; - un champ SOID_value indiquant la valeur de l'identificateur SOID_tag. L'opérateur du service est identifié par un champ présentant la syntaxe suivante: SOID(){ SR19013 HM SOID_tag= 0x14 8 bits SOID_lengCh=OxO3 8 bits SOID_value 24 bits o SOID_value représente un champ identifiant une zone service utilisée dans la carte à puce. Deux options d'embrouillage sont proposées: - Embrouillage systématique du flux descendant; - Embrouillage activé par le serveur WEB 17. La figure 4 illustre schématiquement l'embrouillage activé par le serveur WEB 17 (étape (c)) sur initiative du client (étape (a)). Dans ce cas, un démon actif sur le serveur WEB 17 envoie une requête dactivation à l'embrouilleur IP (étape (b)) sur réception d'une requête HTTP (a) du client sur un lien avec le paramètre "embrouillage à activer " (mot clé dans 1'URL ht tp: //@IP: por t /prog_embrou i 11 é/nom_progra rne,) Le scénario d'embrouillage est le suivant: 1) Le serveur de flux 6 envoie des datagrammes IP 23 en mode point-à-point ou en mode Multipoint. L'adresse de destination des datagrammes 23 est celle du client (point-àpoint) ou bien une adresse de diffusion (Multipoint). 2) L'embrouilleur IP filtre éventuellement les datagrammes IP 23 dont l'adresse d'origine est celle du serveur de flux 6 et maintient une session d'embrouillage par adresse de destination. Ce filtre agit au niveau Ethernet dans le schéma de la figure 4. SR19013 HM 3) L'embrouilleur IP concatène ensuite l'entête 24 (access_control_header) au datagramme IP 23 qui est embrouillé à l'étape 2 puis envoie ce champ sur une pile UDP sur la même adresse de destination que le datagramme initial. 4) Les datagrammes à destination du serveur de flux 6 ne sont pas interceptés par l'embrouilleur IP. Pour réaliser cette procédure d'embrouillage, l'équipement réalisant l'embrouillage doit connaître les paramètres d'embrouillage. Plusieurs options sont alors possibles: - Informations "cablées " dans une table sur l'embrouilleur IP; - Interrogation par l'embrouilleur IP du serveur WEB 17 dédié centralisant les informations nécessaires; - Mise à j our de l'embrouilleur IP par le serveur WEB 17; - Mise à j our locale de l'embrouilleur, faite par l'exploitant. La valorisation des champs du tunnel UDP/IP en émission est effectuée selon le mécanisme suivant: - L'embrouilleur génère un datagramme IP avec les informations suivantes: 25. L'adresse IP source est l'adresse IP de l'embrouilleur. Cette adresse est une adresse IP publique. L'adresse IP destination est l'adresse de destination du datagramme initial. 30. Le port UDP source est alloué dynamiquement à l'ouverture de la pile UDP. SR19013 HM Le port UDP du flux embrouillé n'est pas le même que le port UDP du flux original afin d'éviter des problèmes de bouclage sur le poste client. Deux possibilités existent pour l' attribution du numéro de port UDP de destination appelé dans la suite port UDP IP-CAS: - Attribution dynamique par un protocole de signalisation entre l'embrouilleur et le désembrouilleur. Ceci suppose l' existence d'une voie de retour entre le client et le serveur; - Valeur de configuration dédiée par une autorité de certification donnce avec les règles suivantes: - Les ports connus sont les ports de 0 et 1023; - Les ports enregistrés sont ceux de 1024 à 49151; - Les ports attribués dynamiquement sont ceux de 49152 à 65535. Procédures en réception: pile virtuelle " IP_CAS " Un logiciel " désembrouilleur " 35 est installé sur le poste client (Windows, Linux, MacOS,...). Deux mises en _uvre sont envisagées, soit l'utilisation d'un Pseudo-driver 40, soit l'utilisation du loopback en mode "raw". 1 - Utilisation d'un Pseudo-driver. La figure 5 illustre ce mode de mise en _uvre. Les données sont reaues sur l' interface du fournisseur daccès 42 au réseau internet 3 (FAI) et remontées via la pile IP 44 de la machine cliente vers le désembrouilleur 35 en attente de données UDP sur le port spécifique IP_CAS. Ce désembrouilleur 35 récupère SR19013 HM les données du datagramme UDP via la pile IP, extrait lentête et désembrouille le datagramme IP d'origine. Le désembrouilleur 35 fournit le datagramme IP au client final 4 en attente de donnces sur le port destination d'origine. Afin de transmettre ce datagramme IP au client final (local à la machine), le pseudo-driver réseau 40 doit être développé sous la pile IP: - Ce pseuJo-driver est en attente de données en provenance du désembrouilleur 35 et les fournit à la pile IP. - L'application finale est en attente sur son port particulier et réaupère normalement les données en clair après désencapeulation du datagramme IP d'origine par la pile IP/TCPouUDP. Cette solution peut être implémentée sur un système d'exploitation permettant l'ajout d'un 2ème driver réscau sous la pile IP de la machine. Le routage des drivers FAI 42 et pseuJo-driver 40 au niveau de la couche IP se fait sur une adresse IP propre à chaque driver réseau selon le mécanisme suivant: (1) arrivée du paquet UDP sur le port IP_CAS, (2) réaupération du datagramme IP 23 embrouillé, (3) passage du datagramme IP d'origine désembrouillé au pseudo-driver, (4) réaupération des données sur le port Destination par le client 4. Ce mécanisme permet la récupération du datagramme d'origine 23 sans modification, rendant la fonction de désembrouillage complètement indépendante du client SR19013 HM final. Il utilise seulement la pile IP en mode UDP/TCP en réception de donnces. 2 -Uti li sat ion du mode RAW du loopLack Comme cela est illustré par la figure 6, les données sont recues sur l' interface FAI 42 et remontées via la pile IP 44 de la machine cliente vers le désembrouilleur 35 en attente de données UDP sur le port spécifique IP_CAS. Le désembrouilleur 35 réaupère les données du datagramme UDP via la pile IP 44 extrait l'entête 24 et désembrouille le datagramme IP 23 d'origine. Le désembrouilleur 35 fournit ce datagramme IP 23 au client final en attente de données sur le port destination d'origine en UDP ou en TCP. Le datagramme IP 23 est ré-émis dans la pile FAI/IP 42 via la pile IP 44 en passant en adresse IP destination l'adresse IP loopback de la machine (127.0.0.0). Cette ré-émission s'effectue en mode RAW car les données ré émises constituent une trame IP complète qui ne doit pas être modifiée. Le mécanisme de loopLack de la pile IP 44 remonte donc les données sans les ré-émettre. Le désembrouilleur 35 est en attente sur son port particulier et récupère normalement les données en clair après désencapeulation du datagramme IP par la pile IP/TCP/UDP. Cette solution peut être implémentée sur un système d'exploitation permettant l'utilisation du mode RAW de la pile IP 44 en loopLack côtéémetteur et se fait selon le mécanisme suivant: (1) arrivoe du paquet UDP sur le port IP_CAS, SR19013 HM (2) récupération du datagramme IP embrouillé, (3) passage du datagramme IP d'origine désembrouillé (avec l'adresse IP de destination remplacée par 127.0.0.0) au pseudo-driver en mode RAW et loopLack, (4) récupération des données sur le port Destination par le client final 4. Côté client, ce mécanisme utilise seulement la pile IP 44 en mode UDP/TCP en réception de données pour les passer au désembrouilleur 35 comme en émission de données pour les ré émettre vers l'applicatif final. La figure 7 représente schématiquement un système dembrouillage de données dans un environnement Point- à-Point selon l' invention. Ce système comporte un terminal d'un usager 4, un fournisseur de service 6, un générateur d'ECM 12, une base de données 16, un serveur de présentation de l'offre 64, un éditeur de conditions d'accès 66, une passerelle de commande audiovisuelle de type RTSP 72, un fournisseur d'accès à l'internet 74. Les étapes suivantes décrivent l'accès d'un usager à un service de VOD en utilisant une carte à mémoire. Le principe peut être étendu à d'autres types de services Point-à-Point. L'accès commence par une phase d'authentification de l'abonné. Cette phase se déroule juste après la connexion de l'abonné au fournisseur d'accès à l'internet 74. Au cours de cette session, le terminal de l'usager 4 remonte, son adresse IP, affectée de facon dynamique par le fournisseur d'accès 74 au moment de la connexion SR19013 HM au réseau, et l'UA (unique address, en anglais) de sa carte. Phase 1: Présentation de l'offre. L'usager effectue une requête HTTP sur un serveur de présentation de l'offre 64. Le terminal de l'usager 4 recoit une page lui présentant l'offre des services en terme d'acquisition de droits et en terme de présentation des contenus. La présentation de la page est optionnelle et peut être gérée directement par l'opérateur. La page n'apparaît alors que sur demande de l'abonné, lors de la recharge de droits par exemple. Phase 2: Sélection du programme La phase 2 présuppose que l'usager a sélectionné un service particulier (ex choix d'un film dans un service de VoD). Deux actions se déroulent en parallèle: - La première à destination du navigateur.: phase 2; - La seconde à destination du système d'embrouillage: phase 2'. Dans cette seconde phase, le serveur de présentation renvoie au terminal dans la réponse HTTP 1!URE complète du film (ex:http://servl.nom-du film. ram); Phase 3: lancement du programme d'exéaution du film player Le navigateur de l'usager active ce programme (dans l'exemple présent, RealPlayer) en lui passant en paramètre le fichier "nom_du_film.ram". SR19013 HM Le player se connecte à 1IURE htÉp://servl/nom-du- film.ram. Une session de commandes RT8P (start, stop, play, rewind, forward, etc....) est alors ouverte entre le terminal 4 et la passerelle de commande 72 redirigeant la requête RSTP vers le serveur de flux le plus adapté, la passerelle de commande 72 et le serveur * de flux 6 sont éventuellement confondus. Phase 4: Connexion serveur de flux Le serveur RTSP ouvre alors une session TCP avec le serveur concerné par la délivrance du film (ici servl. .). Phase 5: lancement de la diffusion Le serveur de flux 6 émet ensuite le film dans des datagrammes UDP/IP vers la passerelle d'embrouillage avec pour adresse source, l'adresse du serveur et pour adresse destinataire, l'adresse du client final. Phase 6: Embrouillage du programme La passerelle d'embrouillage dont les filtres Point-à-Point sont activés de facon automatique dès la détection des services Point-à-Point dans la base 16, peut alors embrouiller de facon générique (sur origine) ou personnalisoe (sur destinataire) ou suivant l'URL les données descendantes. Phase 7: La fermeture d'une session Point-à-Point Une session Point-àPoint peut être close par la passerelle d'embrouillage sur time-out (non réception de paquets d'une adresse source ou destinataire donnée pendant secondes). La valeur maximale du time-out Point-à-Point est précisée lors de la configuration des paramètres généraux de l'équipement. SR19013 HM j - 2823936 EXE uccess_confrol_haoder()l occess_con11_heudess10d_sequence 32 blis hendojng1h 16 blip versIon_number 8 bRs selce_lD 1G bits poyloodJypa 8 bits poylood_scmblg_con1mi - 2 bits RUE O G bits (poYlood_scrombllng_control!=001 sdMmbl[ng_olgod1hm_pa 3 bits porlood_poddinglze 8 bits poylood-descmmbng_woy 3 bits cleopoylood_CRC32 32 bits IVopem10_1D_leng1h 8 bits IVopero10clD_yolue IVoperu10_1D_leng1h* 8 bits RUf 1 2 bits #(poylogd_descromblg_woy==OO1)I ECH_CA_descp10flog 1 bl1 EWH_CA_descdp10110g 1 bFf fig 1 bl1 RUF 2 5 blts (ECY_CA_descp10Dog==1)1 Nb_ECH_CA_descrlp+or 8 bits ECH_CA_descdp10ovardon_number 8 bits for (l=O; T REVENDICATIONS 1. Procédé d'émission d'informations (20) avec contrôle d'accès à travers un réseau (3) utilisant un protocole du type IP, caractérisé en ce qu'il comporte les étapes suivantes: A l'émission: - embrouiller un premier datagramme (23); - définir un entête (24) comportant au moins une donnée identifiant les moyens de contrôle d'accès; - concaténer cet entête (24) avec le premier datagramme embrouillé (23) pour créer un bloc de données (26); - encapsuler le bloc de données (26) dans un deuxième datagramme IP (30); - émettre ce deuxième datagramme IP (30) à travers le réseau; à la réception: - extraire le bloc de données du datagramme requ; - extraire l'entête (24); - désembrouiller le premier datagramme (23) si l'accès à ces données est autorisé; - délivrer les données désembrouillées. 2. Procédé selon la revendication 1, caractérisé en ce que le bloc de données (26) est encapsulé dans un paquet UDP. 3. Procédé selon la revendication 1, caractérisé en ce que le bloc de données (26) est encapsulé directement dans un datagramme IP. -. 4. Procédé selon l'une des revendications 1 à 3, caractérisé en ce que l'étape d'embrouillage comporte les phases suivantes: - définir les services à embrouiller par un label auquel correspond une adresse IP source ou une adresse IP destination; - saisir au moins une condition d'accès ou au moins une clé secrète. 5. Procédé selon la revendication 1, caractérisé en ce que le bloc de données (26) comporte: - l'entête (24) (Access_control_header) véhiculant les informations nécessaires au traitement par un terminal (4) des données transportées; - une séquence (Payload) représentant les données utiles (20) à embrouiller. 6. Procédé selon l'une des revendications précédentes, caractérisé en ce que le bloc de données (26) respecte la syntaxe suivante: CAS_data_unit() { Access_control_header() p octets Payload q octets } 7. Procédé selon la revendication 5, caractérisé en ce que la séquence (payload) respecte la syntaxe suivante: payload() { data bytes n octets . padding bytes p octets, (p pouvant prendre la valeur O) } 8. Procédé selon la revendication 5, caractérisé en ce que l'entête (24) comporte: - un premier champ (header_length) représentant la longueur totale de cet entête (24); - un deuxième champ (payload_scrambling_control) indiquant le mode d'application de l'embrouillage des informations (20). 9. Procédé selon la revendication 8, caractérisé en ce que ltentête (24) comporte en outre un champ (EDC) représentant une séquence de détection d'erreurs. 10. Procédé selon la revendication 8, caractérisé en ce que, si (payload_scrambling_control 00) l'entête (24) comporte en outre un champ (payload_descrambling_way) indiquant le mode de désembrouillage des informations (20). 11. Procédé selon la revendication 10, caractérisé en ce que, si (payload_descrambling_way = 001), l'entête (24) comporte en outre un champ ( ECM_CA_ descriptor_flag) indiquant la présence d'au moins un descripteur d'accès conditionnel (ECM_CA_ descriptor) dans l'entête (24), et un champ ( ECM_ flag) indiquant, lorsque sa valeur est égale à 1, la présence d'au moins un champ ECM() représentant un message de contrôle d'accès dans l'entête (24). 12. Procédé selon la revendication 11, caractérisé en ce que si (ECM_CA_descriptor_flag=1), l'entête (24) comporte en outre un champ (Nb_ECM_CA_descriptor) indiquant le nombre de blocs (ECM_CA_descriptor) présents dans cet entête (24). 13. Procédé selon la revendication 8, caractérisé en ce que l'entête (24) comporte en outre un champ (access_control_header_start_sequence) permettant d' identifier le début de l'entête (24), un champ (version_number) indiquant la version courante de l'entête (24), un champ (service_ID) indiquant la référence du service utilisé, un champ binaire (payload_type) indiquant le type de données transmises, et un champ (RUFO) réservé pour un usage futur. 14. Procédé selon la revendication 10, caractérisé en ce que l'entête (24) comporte en outre un champ (scrambling_algorithm_type) destiné à indiquer le type d'algorithme utilisé pour embrouiller le datagramme (23), et un champ correcteur d'erreur (CRC_32) des données utiles désembrouillées. 15. Procédé selon la revendication 14, caractérisé en ce que, si le datagramme (23) est embrouillé par un algorithme fonctionnant dans le mode bloc, l'entête (24) comporte en outre: - un champ (payload_padding_size) précisant le nombre d 'octets de bourrage rajoutés en fin des informations (20); ,, . - un champ (IVOperator_ID_length) indiquant, lorsque sa valeur est différente de zéro, la présence et la longueur d'un champ vecteur d'initialisation de l'embrouilleur; - un champ (IVOperator_ID_value) indiquant, lorsque la valeur de (IVOperator_ID_length) est différente de zéro, la valeur du vecteur d'initialisation de l'embrouilleur, et - un champ (RUF1) réservé pour un usage futur. 16. Procédé selon la revendication 11, caractérisé en ce que, l'entête (24) comporte en outre un champ ( EMM_CA_ descriptor_flag) indiquant, quand sa valeur est égale à 1, la présence d'au moins un descripteur d'accès conditionnel (ECM_CA_ descriptor) dans l'entête du datagramme embrouillé (23), un champ (RUF2) réservé pour un usage futur. 17. Procédé selon la revendication 12, caractérisé en ce que l'entête (24) comporte en outre un champ ( ECM_CA_ descriptor_version_number) indiquant la version suivante du bloc (ECM_CA_descriptor). 18. Procédé selon la revendication 16, caractérisé en ce que, si ( EMM_CA_ descriptor_flag = 1), l'entête (24) comporte en outre un champ (EMM_ CA _descriptor_version_number) indiquant la version suivante du bloc ( EMM_CA _descriptor). 19. Procédé selon la revendication 11, caractérisé en ce que, si (ECM_ flag = 1), l'entête (24) comporte en outre un champ ( NB_ECM) indiquant le nombre d' ECM dans l'entête (24) du datagramme embrouillé. 20. Procédé selon la revendication 10, caractérisé en ce que, si (payload_descrambling_way=010), l'entête (24) comporte un champ (RUF3) réservé pour un usage futur. 21. Procédé selon la revendication 11, caractérisé en ce que le message de contrôle d'accès comporte: - un pointeur (ECM_ index) destiné à différentier plusieurs ECM pour sélectionner un ECM particulier pour le désembrouillage; - une table ( ECM_ table) contenant les données de 1' ECM et les instructions de changement de phase. 22. Procédé selon la revendication 21, caractérisé en ce que la table ( ECM table) comporte: - un champ d' identification (table_id); - un champ indiquant la longueur d'un ECM, (ECM_ length). 23. Procédé selon la revendication 17, caractérisé en ce que le descripteur d'accès conditionnel (ECM_CA_ descriptor) comporte: - un champ (descriptor_tag) indiquant le début d'un descripteur d'accès conditionnel ECM; - un champ ( ECM_CA_ descriptor_length) indiquant la longueur; ,. . un champ (CA_system_ID) représentant un identificateur du système de contrôle d'accès utilisé; un pointeur (ECM_index). s 24. Procédé selon la revendication 14, caractérisé en ce que l' identificateur du type d' algorithme de cryptage comporte: - un identificateur (CI_tag); - un champ (CI-length) indiquant la longueur de l'identificateur (CI_tag); - un champ (CI_value) indiquant la valeur de l'identificateur (CI-tag). 25. Procédé selon l'une des revendications précédentes, caractérisé en ce que l'opérateur du service est identifié par un champ comportant: - un identificateur (SOID_tag) du bloc permettant de décrire la zone de l'opérateur de service utilisé dans la carte à puce; - un champ (SOID_length) indiquant la longueur de ladite zone; - un champ (SOID_value) indiquant la valeur de l'identificateur ( SOID_ tag). 26. Procédé selon la revendication 2, caractérisé en ce que un port UDP source est alloué dynamiquement à l'ouverture du lien UDP. 27. Procédé selon la revendication 2, caractérisé en ce l' attribution du numéro du port UDP de destination est réalisée dynamiquement par un protocole de signalisation entre l'embrouilleur et le désembrouilleur. 28. Procédé selon la revendication 2, caractérisé en ce le numéro de port UDP de destination est une valeur dédiée par une autorité de certification. 29. Procédé selon les revendications 27 et 28, caractérisé en ce que la réception des datagrammes IP/UDP par le client final comporte les étapes suivantes: - recevoir le deuxième datagramme IP (30), - recevoir le paquet UDP sur le port UDP statique ou - dynamique précédemment ouvert, - récupérer et désembrouiller le bloc de données (26) , - extraire l'entête (24), - envoyer le premier datagramme IP (23) désembrouillé à un pseuJo-driver, - extraire les données du premier datagramme (23); - envoyer le paquet extrait à l' application destination. 30. Procédé selon la revendication 28, caractérisé en ce que la réception des datagrammes UDP par le client final comporte les étapes suivantes: recevoir le deuxième datagramme IP (30); - recevoir le paquet UDP sur le port statique ou dynamique ouvert précédemment; - récupérer et désembrouiller le bloc de données (26); _., - $, j. ';;: - extraire l'entête (24); - ré-emettre le premier datagramme IP (26) sur l'adresse loopback de la pile; - extraire les données du premier datagramme (23), pour les envoyer à l' application destinataire. 31. Procédé selon l'une des revendications 1 à 30, caractérisé en ce que les services IP transmis sont des flux audiovisuels sur IP. 32. Procédé selon l'une des revendications 1 à 30, caractérisé en ce que les services IP transmis sont des données transmises par satellite via le réseau IP. 33. Emetteur de données embrouillées à travers un réseau du type IP apte à mettre en _uvre le procédé selon l'une des revendications 1 à 32. 34. Emetteur selon la revendication 33, caractérisé en ce qu'il comporte des moyens pour associer aux datagrammes IP (23) une entête (24) comportant au moins une donnée identifiant les moyens de contrôle d'accès et une indication de la méthode d'embrouillage utilisée. 35. Emetteur selon la revendication 34, caractérisé en ce qu'il comporte en outre des moyens pour définir les services à embrouiller par un label auquel correspond une adresse IP source ou une adresse IP destination; des moyens pour saisir au moins une condition d'accès ou au moins une clé secrète. 36. Emetteur selon la revendication 35, caractérisé en ce qu'il comporte un serveur (6) de flux de données IP, une passerelle (8) comportant un embrouilleur IP, un générateur d'ECM (12), un générateur d'EMM (14) et une base de données (16). 37. Récepteur apte à recevoir des données embrouillées selon les revendications 1 à 32. 38. Récepteur selon la revendication 37, caractérisé en ce qu'il comporte des moyens pour extraire l'entête (24) d'un bloc de données embrouillées (26) et des moyens pour activer au moins une condition d'accès ou au moins une clé secrète. 39. Système d'embrouillage et de contrôle d'accès dans un réseau de type IP, caractérisé en ce qu'il comporte un émetteur selon la revendication 33 et un récepteur selon la revendication 37. 40. Dispositif d'embrouillage et de contrôle d'accès à des services IP comportant un émetteur selon la revendication 36, caractérisé en ce qu'il comporte en outre une interface homme-machine destince à définir les services à embrouiller et à saisir au moins une condition daccès ou une clé secrète. ^ ,p,,:,', 'r I. 41. Dispositif salon la revendication 40, caractérisé en ce que les moyens de contrôle d'accès comportent une carte à mémoire pour le transport de la clé secrete.