CA2444435A1 - Procede et systeme d'acces conditionnel a des services ip - Google Patents
Procede et systeme d'acces conditionnel a des services ip Download PDFInfo
- Publication number
- CA2444435A1 CA2444435A1 CA002444435A CA2444435A CA2444435A1 CA 2444435 A1 CA2444435 A1 CA 2444435A1 CA 002444435 A CA002444435 A CA 002444435A CA 2444435 A CA2444435 A CA 2444435A CA 2444435 A1 CA2444435 A1 CA 2444435A1
- Authority
- CA
- Canada
- Prior art keywords
- header
- field
- ecm
- data
- datagram
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
- H04L63/0457—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply dynamic encryption, e.g. stream encryption
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/22—Parsing or analysis of headers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
Abstract
Procédé d'émission d'informations (20) avec contrôle d'accès à travers un réseau (3) utilisant un protocole du type IP. Selon l'invention, à l'émissio n: 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 (26) du datagramme reçu; 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.
Description
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 ceuvre 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 àe 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 nécessite pas la modification du serveur ou des logiciels applicatifs installés chez le client. Cependant, l'embrouillage est
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 ceuvre 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 àe 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 nécessite pas la modification du serveur ou des logiciels applicatifs installés chez le client. Cependant, l'embrouillage est
2 généralement appliqué à l'ensemble du trafic entre le client et 1e serveur et pas seulement à un service spécifique. Aussi, dans la mesure où le trafic comporte des données qui ne nécessitent 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 point-multipoint, 1a voie de retour n'est pas nécessaire, par exemple transmission par satellite (multicast en ang-lais).
Par ailleurs, l'échange des clés permettant d'accéder aux contenus s'effectue par le biais de l'utilisation d'aïgorithmes à cïé 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évisicn numérique par exemple (pay per view, abonnement, etc.... ) et qui sont inscrits dans un processeur de sécurité.
Citons également le standard SSL (Secure 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 protégé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 protégées par SSL naviguent généralement à travers une connexion au port 443 du serveur TCP. Aussi, si le
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 point-multipoint, 1a voie de retour n'est pas nécessaire, par exemple transmission par satellite (multicast en ang-lais).
Par ailleurs, l'échange des clés permettant d'accéder aux contenus s'effectue par le biais de l'utilisation d'aïgorithmes à cïé 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évisicn numérique par exemple (pay per view, abonnement, etc.... ) et qui sont inscrits dans un processeur de sécurité.
Citons également le standard SSL (Secure 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 protégé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 protégées par SSL naviguent généralement à travers une connexion au port 443 du serveur TCP. Aussi, si le
3 serveur reçoit une connexion au port 443, il applique l'embrouillage SSL à cette connexion et transmet les données IP au client. Cette procédure permet au client et au serveur de distinguer les données protégé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 données 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 àe façon générique et de con trôle.r 1 ' 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 ;
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 données 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 àe façon générique et de con trôle.r 1 ' 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 ;
4 - 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;
- Émettre ce deuxième datagramme IP à travers le réseau ; et A la réception .
- extraire le bloc de données du datagramme reçu ;
- extraire l'entête ;
- désembrouiller le premier datagramme si l'accès à ces données est autorisé ;
- délivrer les données désembrouillées.
Selon l'invention, le bloc de données est encapsulé 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'embrcuillage 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 données comporte - l'entête (Access control header) véhiculant les informations nécessaires au traitement par un terminal utilisateur des données transportées ; et - Une séquence (Payload) représentant les informations à embrouiller.
Selon l'invention, le bloc de données respecte la syntaxe suivante .
CAS DATA UNIT() {
Access control header() p octets
- 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;
- Émettre ce deuxième datagramme IP à travers le réseau ; et A la réception .
- extraire le bloc de données du datagramme reçu ;
- extraire l'entête ;
- désembrouiller le premier datagramme si l'accès à ces données est autorisé ;
- délivrer les données désembrouillées.
Selon l'invention, le bloc de données est encapsulé 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'embrcuillage 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 données comporte - l'entête (Access control header) véhiculant les informations nécessaires au traitement par un terminal utilisateur des données transportées ; et - Une séquence (Payload) représentant les informations à embrouiller.
Selon l'invention, le bloc de données respecte la syntaxe suivante .
CAS DATA UNIT() {
Access control header() p octets
5 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 0) 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édiée par une autorité de régulation) ou bien dynamiquement par un protocole de signalisation entre 1'embrouilleur 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 deuxième datagramme IP ;
payload() {
data bytes n octets padding bytes p octets, (p pouvant prendre la valeur 0) 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édiée par une autorité de régulation) ou bien dynamiquement par un protocole de signalisation entre 1'embrouilleur 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 deuxième datagramme IP ;
6 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 pseudo-driver ;
- 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 loopback 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 données transmises par satellite via un réseau IP.
Les données sont émises à travers un réseau 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.
- récupérer et désembrouiller le bloc de données ;
- extraire l'entête ;
- envoyer le datagramme IP désembrouillé à un pseudo-driver ;
- 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 loopback 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 données transmises par satellite via un réseau IP.
Les données sont émises à travers un réseau 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.
7 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'E1~IM et une base de données.
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 DISpOSltif d'embr0;~.1113g2 2t de Contrôle d'accès de services IP selon l'invention comporte une interface homme-machine destinée à 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
- 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'E1~IM et une base de données.
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 DISpOSltif d'embr0;~.1113g2 2t de Contrôle d'accès de services IP selon l'invention comporte une interface homme-machine destinée à 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
8 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 ;
- 1a figure 4 illustre schématiquement un premier hl0de Ge rvCer.~tl0h miS '.-'.n wüvre CLanS le prOCédé SelCn l' lnVentlOn ;
- la figure 5 illustre schématiquement un deuxième mode de réception mis en ceuvre 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 interconnectés dans un réseau local 2 (LAN, Local Area Network en anglais) qui est relié, via 1e réseau internet 3, à plusieurs
- 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 ;
- 1a figure 4 illustre schématiquement un premier hl0de Ge rvCer.~tl0h miS '.-'.n wüvre CLanS le prOCédé SelCn l' lnVentlOn ;
- la figure 5 illustre schématiquement un deuxième mode de réception mis en ceuvre 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 interconnectés dans un réseau local 2 (LAN, Local Area Network en anglais) qui est relié, via 1e réseau internet 3, à plusieurs
9 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, Entitlement 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 nécessitant 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 intégré à la passerelle 8 avant d'être transmis à travers J_e réseau interner 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.
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 5 (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 n'utilisant pas de carte à mémoire (tableau I), et peut être plus élevée dans les systèmes mettant en oeuvre une
Les données IP délivrées par le serveur de flux 6 peuvent être des services audio visuels nécessitant 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 intégré à la passerelle 8 avant d'être transmis à travers J_e réseau interner 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.
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 5 (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 n'utilisant pas de carte à mémoire (tableau I), et peut être plus élevée dans les systèmes mettant en oeuvre une
10 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 Origine(source Mot de Conditions filtrer et ou dest.) contrle d'accs embrouiller Service @ au format S et/ou D CA i j IP VX
Dans les systèmes mettant en oeuvre 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 oeuvre 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 .
FEUILLE DE REMPLACEMENT (REGLE 26)
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 Origine(source Mot de Conditions filtrer et ou dest.) contrle d'accs embrouiller Service @ au format S et/ou D CA i j IP VX
Dans les systèmes mettant en oeuvre 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 oeuvre 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 .
FEUILLE DE REMPLACEMENT (REGLE 26)
11 - 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éseau IP repose sur le principe suivant .
- Embrouillage du premier datagramme IP 23 (PDU, Protocole Data Unit en anglais).
- définition d'un 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 ceuvre 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 ;
- 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éseau IP repose sur le principe suivant .
- Embrouillage du premier datagramme IP 23 (PDU, Protocole Data Unit en anglais).
- définition d'un 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 ceuvre 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 ;
12 - 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 ) _cr r-éseY:tant ~.:~_c ~é:~uence -!e détection d' erreurs.
Selon l'invention, si (payload-scrambling-contro1~00), 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 1a 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 à l, la présence d'au moins un champ ECM() dans l'entête du datagramme embrouillé
23.
Si (ECM CA descriptor flag~l), l'entête 24 comporte un champ (Nb-ECM-CA-descriptor) indiquant le
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 ) _cr r-éseY:tant ~.:~_c ~é:~uence -!e détection d' erreurs.
Selon l'invention, si (payload-scrambling-contro1~00), 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 1a 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 à l, la présence d'au moins un champ ECM() dans l'entête du datagramme embrouillé
23.
Si (ECM CA descriptor flag~l), l'entête 24 comporte un champ (Nb-ECM-CA-descriptor) indiquant le
13 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 (RUFO) réservé pcur 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 corre~~t~ur d'erreur (CP,C-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 1a 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_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.
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 (RUFO) réservé pcur 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 corre~~t~ur d'erreur (CP,C-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 1a 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_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.
14 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 d'accè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 données (EM~i-CA desr~_ptor) .
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 }
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 .
5 - un champ d'identification (table_id) - un champ indiquant la longueur d'un ECM, (ECM-length) ECM table(), présente la structure suivante .
ECM table(){
10 table id = 0x80 ou 0x81 ~ 8 bits NOT USED 4 bits ECM length -12 bits NOT USED 8 bits ~-~r ( 1 = 0 ~ i <tl ~ 1++) {
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 données (EM~i-CA desr~_ptor) .
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 }
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 .
5 - un champ d'identification (table_id) - un champ indiquant la longueur d'un ECM, (ECM-length) ECM table(), présente la structure suivante .
ECM table(){
10 table id = 0x80 ou 0x81 ~ 8 bits NOT USED 4 bits ECM length -12 bits NOT USED 8 bits ~-~r ( 1 = 0 ~ i <tl ~ 1++) {
15 ECM data bytes 8 bits où, table id raprésen~e »n champ en 8 bits qui identifie le type de données contenues dans la table ;
- 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 d'un descripteur ECM ;
- un champ (CA-system-ID) représentant un identificateur du système de contrôle d'accès utilisé ;
- un pointeur (ECM-index).
A titre d'exemple, le descripteur d'accès conditionnel (ECM CA descriptor) présente 1e format suivant .
ECM CA descriptor(){
- 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 d'un descripteur ECM ;
- un champ (CA-system-ID) représentant un identificateur du système de contrôle d'accès utilisé ;
- un pointeur (ECM-index).
A titre d'exemple, le descripteur d'accès conditionnel (ECM CA descriptor) présente 1e format suivant .
ECM CA descriptor(){
16 Descriptor-tag = 0x09 8 bits ECM CA descriptor length 8 bits CA system-ID 16 bits ECM index 8 bits for (i = 0 ; i<N ; i++) {
private data bytes 8 bits et l'identificateur du type d'algorithme comporte .
- un identificateur CI tag ;
- un champ CI-length indiquant la longueur de l'identificateur ; -- un champ CI value indiquant la - valeur de ~'~C?W!t'~riCat~ur CI-~ag.
L'identificateur du type d'algorithme 1 5 d' e~:brou-1 l~: J~. j:~-:se~_te 1 e forma ~ sui vaut rI ( ~ r CI tag= 0x13 8 bits CI length=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_length 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() {
private data bytes 8 bits et l'identificateur du type d'algorithme comporte .
- un identificateur CI tag ;
- un champ CI-length indiquant la longueur de l'identificateur ; -- un champ CI value indiquant la - valeur de ~'~C?W!t'~riCat~ur CI-~ag.
L'identificateur du type d'algorithme 1 5 d' e~:brou-1 l~: J~. j:~-:se~_te 1 e forma ~ sui vaut rI ( ~ r CI tag= 0x13 8 bits CI length=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_length 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() {
17 SOID tag= 0x14 8 bits SOID length=0x03 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 d'activation à 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 l'URL http ://@IP .
port/prog embrouillélnom programme,).
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.
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 d'activation à 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 l'URL http ://@IP .
port/prog embrouillélnom programme,).
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.
18 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 à jour de l'embrouilleur IP par le serveur WEB 17 ;
- Mise à jour locale de l' embrcuilleur, 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 ~ 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.
~ Le port UDP source est alloué dynamiquement à
l'ouverture de la pile UDP.
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 à jour de l'embrouilleur IP par le serveur WEB 17 ;
- Mise à jour locale de l' embrcuilleur, 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 ~ 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.
~ Le port UDP source est alloué dynamiquement à
l'ouverture de la pile UDP.
19 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 donnée 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 ceuvre 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 ceuvre. Les données sont reçues sur l'interface du fournisseur d' accè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 les données du datagramme UDP via la pile IP, extrait l'entête <discriminateur - access-control-header> et désembrouille le datagramme IP d'origine.
Le désembrouilleur 35 fournit le datagramme IP au 5 client final 4 en attente de données 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 .
10 - Ce pseudo-driver est en attente de données en provenance du désembrouill.eur_ 35 et les fournit à la pile IP.
- L'application finale est en attente sur son port particulier et récupère normalement les données en 15 clair après désencapsulation du datagramme IP d'origine par la pile IP/TCPouUDP.
Cette solution peut être implémentée sur un système d' exploitati on permettant 1' ajout d' un 2éme driver réseau sous la pile IP de la machine. Le routage
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 donnée 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 ceuvre 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 ceuvre. Les données sont reçues sur l'interface du fournisseur d' accè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 les données du datagramme UDP via la pile IP, extrait l'entête <discriminateur - access-control-header> et désembrouille le datagramme IP d'origine.
Le désembrouilleur 35 fournit le datagramme IP au 5 client final 4 en attente de données 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 .
10 - Ce pseudo-driver est en attente de données en provenance du désembrouill.eur_ 35 et les fournit à la pile IP.
- L'application finale est en attente sur son port particulier et récupère normalement les données en 15 clair après désencapsulation du datagramme IP d'origine par la pile IP/TCPouUDP.
Cette solution peut être implémentée sur un système d' exploitati on permettant 1' ajout d' un 2éme driver réseau sous la pile IP de la machine. Le routage
20 des drivers FAI 42 et pseudo-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écupération du datagramme IP 23 embrouillé, (3) passage du datagramme IP d'origine désembrouillé au pseudo-driver, (4) récupération des données sur le port Destination par 1e 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
(1) arrivée du paquet UDP sur le port IP CAS, (2) récupération du datagramme IP 23 embrouillé, (3) passage du datagramme IP d'origine désembrouillé au pseudo-driver, (4) récupération des données sur le port Destination par 1e 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
21 final. Il utilise seulement la pile IP en mode UDP/TCP
en réception de données.
2 -Utilisation du mode RAW du loopback Comme cela est illustré par la figure 6, les données sont reçues sur l'interface FAI 42 et remontées via la pile IP 44 de la machine cliente vers 1e désembrouilleur 35 en attente de données UDP sur le port spécifique IP-CAS. Le désembrouilleur 35 récupère les données du datagramme UDP via la pile IP 44 extrait l'entête 24 <discriminateur - access control.header> et désembrouille le datagramme IP 23 d'o-rigine. 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 1a machine (127Ø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 loopback 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ésencapsulation 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 loopback côté émetteur et se fait selon le mécanisme suivant .
(1) arrivée du paquet UDP sur le port IP-CAS,
en réception de données.
2 -Utilisation du mode RAW du loopback Comme cela est illustré par la figure 6, les données sont reçues sur l'interface FAI 42 et remontées via la pile IP 44 de la machine cliente vers 1e désembrouilleur 35 en attente de données UDP sur le port spécifique IP-CAS. Le désembrouilleur 35 récupère les données du datagramme UDP via la pile IP 44 extrait l'entête 24 <discriminateur - access control.header> et désembrouille le datagramme IP 23 d'o-rigine. 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 1a machine (127Ø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 loopback 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ésencapsulation 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 loopback côté émetteur et se fait selon le mécanisme suivant .
(1) arrivée du paquet UDP sur le port IP-CAS,
22 (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) au pseudo-driver en mode RAW
et loopback, (4) récupération des données sur 1e 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 d'embrouillage 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 à 1'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 façon dynamique par le fournisseur d'accès 74 au moment de la connexion
et loopback, (4) récupération des données sur 1e 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 d'embrouillage 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 à 1'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 façon dynamique par le fournisseur d'accès 74 au moment de la connexion
23 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 reçoit 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 ''~' ~Tr~??_c~,? t c 1 OY'3 C'.le Si?r 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 para11é1e .
- 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
l'UFtL complète du film (ex :http://servl.nom-du film.ram) ;
Phase 3 . lancement du programme d'exécution 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".
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 reçoit 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 ''~' ~Tr~??_c~,? t c 1 OY'3 C'.le Si?r 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 para11é1e .
- 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
l'UFtL complète du film (ex :http://servl.nom-du film.ram) ;
Phase 3 . lancement du programme d'exécution 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".
24 Le player se connecte à l'uRL http://servl/nom-du-film.ram. Une session de commandes RTSP (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 1e serveur de flux le plus adapté, 1a passerelle de commande 72 et le serveur de flux 6 sont éventuellement con fondus.
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 servi..).
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 façon automatique dès 1a détection des services Point-à-Point dans la base 16, peut alors embrouiller de façon générique (sur @
origine) ou personnalisée (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 X secondes). La valeur maximale du tune-out Point-à-Point est précisée lors de la configuration des paramètres généraux de l'équipement.
ANN~'X~' access_centrol_header(~~
access_control_header_starf_sequence 32 bits header_length 16 bits version_number 8 bits service_ID 16 bits payload_type 8 bits payload_scrambling_control 2 'dits RUF 0 bits if (payload_scrambling_control !=00)~
scrarnbling_algorithm_type 3 bits payload_padding_size 8 bits payload-descrambling_way 3 bits clear_payload_CRC32 32 bits IYoperator_ID_length 8 bits IVoperator_ID_value IYoperator_ID-lengthx 8 bits RUF 1 2 bits ~"c,-e~i;bl!n waV=-001 )~
iff DCYlccri _ 1 bit ECM_CA_desciptor_flag EMM_CA_descriptor_flcg 1 bit ECM_f!eg 1 bit RUF 2 ~ bits if (E C4!_CA_descriptor_f lag==1 )~
Nb_ECM_CA_descriptor 8 bits ECM_CA_descriptor_versicn_number 8 bits for (i=C";i<rt;i++)$
ECM_CA_descriotor() if (ECM_CA._descriptor_flag==1 )~ 8 bits EMM_CA_descrip'ror version_number EMM_CA_descriptor() ~f (ECM_flag==1 )~
NB_ECM 8 bits for (i=C;i;i++) ECM~) if (payload_descrambling_way==O10) RUF 3 16 bits 8 bits EDC
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 servi..).
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 façon automatique dès 1a détection des services Point-à-Point dans la base 16, peut alors embrouiller de façon générique (sur @
origine) ou personnalisée (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 X secondes). La valeur maximale du tune-out Point-à-Point est précisée lors de la configuration des paramètres généraux de l'équipement.
ANN~'X~' access_centrol_header(~~
access_control_header_starf_sequence 32 bits header_length 16 bits version_number 8 bits service_ID 16 bits payload_type 8 bits payload_scrambling_control 2 'dits RUF 0 bits if (payload_scrambling_control !=00)~
scrarnbling_algorithm_type 3 bits payload_padding_size 8 bits payload-descrambling_way 3 bits clear_payload_CRC32 32 bits IYoperator_ID_length 8 bits IVoperator_ID_value IYoperator_ID-lengthx 8 bits RUF 1 2 bits ~"c,-e~i;bl!n waV=-001 )~
iff DCYlccri _ 1 bit ECM_CA_desciptor_flag EMM_CA_descriptor_flcg 1 bit ECM_f!eg 1 bit RUF 2 ~ bits if (E C4!_CA_descriptor_f lag==1 )~
Nb_ECM_CA_descriptor 8 bits ECM_CA_descriptor_versicn_number 8 bits for (i=C";i<rt;i++)$
ECM_CA_descriotor() if (ECM_CA._descriptor_flag==1 )~ 8 bits EMM_CA_descrip'ror version_number EMM_CA_descriptor() ~f (ECM_flag==1 )~
NB_ECM 8 bits for (i=C;i;i++) ECM~) if (payload_descrambling_way==O10) RUF 3 16 bits 8 bits EDC
Claims (41)
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 1e bloc de données du datagramme reçu ;
- extraire 1'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.
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 1e bloc de données du datagramme reçu ;
- extraire 1'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.
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.
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.
- 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.
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 1a syntaxe suivante :
CAS_data_unit() {
Access_control_header() p octets Payload q octets }.
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 0) }.
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 0) }.
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).
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 l'entête (24) comporte en outre un champ (EDC) représentant une séquence de détection d'erreurs.
en ce que l'entête (24) comporte en outre un champ (EDC) représentant une séquence de détection d'erreurs.
10. Procédé selon 1a revendication 8, caractérisé
en ce que, si (payload_scrambling_control .noteq. 00) l'entête (24) comporte en outre un champ (payload_descrambling_way) indiquant le mode de désembrouillage des informations (20).
en ce que, si (payload_scrambling_control .noteq. 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 1a 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).
en ce que, si (payload_descrambling_way = 001), l'entête (24) comporte en outre un champ (ECM_CA_descriptor_flag) indiquant 1a 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).
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 (RUF0) réservé pour un usage futur.
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 (RUF0) 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.
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_site) 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.
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_site) 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.
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).
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).
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é.
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.
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 l'ECM
et les instructions de changement de phase.
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 l'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).
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 1a longueur ;
- un champ (CA_system_ID) représentant un identificateur du système de contrôle d'accès utilisé ;
- un pointeur (ECM-index).
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 1a longueur ;
- un champ (CA_system_ID) représentant un identificateur du système de contrôle d'accès utilisé ;
- un pointeur (ECM-index).
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).
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).
-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.
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.
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.
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 pseudo-driver, - extraire les données du premier datagramme (23) ;
- envoyer le paquet extrait à l'application destination.
- 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 pseudo-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) ;
- 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.
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) ;
- 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. Émetteur de données embrouillées à travers un réseau du type IP apte à mettre en oeuvre le procédé
selon l'une des revendications 1 à 32.
selon l'une des revendications 1 à 32.
34. Émetteur 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. Émetteur 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.
- 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 destinée à définir les services à embrouiller et à saisir au moins une condition d'accès ou une clé secrète.
41. Dispositif selon 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é secrète.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR01/05318 | 2001-04-19 | ||
| FR0105318A FR2823936B1 (fr) | 2001-04-19 | 2001-04-19 | Procede et systeme d'acces conditionnel a des services ip |
| PCT/FR2002/001337 WO2002087190A1 (fr) | 2001-04-19 | 2002-04-18 | Procede et systeme d'acces conditionnel a des services ip |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2444435A1 true CA2444435A1 (fr) | 2002-10-31 |
Family
ID=8862485
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002444435A Abandoned CA2444435A1 (fr) | 2001-04-19 | 2002-04-18 | Procede et systeme d'acces conditionnel a des services ip |
Country Status (8)
| Country | Link |
|---|---|
| US (1) | US20040128665A1 (fr) |
| EP (1) | EP1396135A1 (fr) |
| JP (1) | JP2004535704A (fr) |
| KR (1) | KR20030092083A (fr) |
| CN (1) | CN1518824A (fr) |
| CA (1) | CA2444435A1 (fr) |
| FR (1) | FR2823936B1 (fr) |
| WO (1) | WO2002087190A1 (fr) |
Families Citing this family (17)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR2839834B1 (fr) * | 2002-05-17 | 2004-07-30 | Viaccess Sa | Procede de distribution de donnees avec controle d'acces |
| FR2890274A1 (fr) * | 2005-08-30 | 2007-03-02 | France Telecom | Procede d'adressage pour le transport de donnees sur un reseau de telecommunication,signal de structure d'adresse, passerelle et programme d'ordinateur correspondants |
| US8023973B2 (en) * | 2007-01-03 | 2011-09-20 | Motorola Solutions, Inc. | Expandable text messaging service protocol for use with a two-way radio transceiver |
| RU2339077C1 (ru) * | 2007-03-13 | 2008-11-20 | Олег Вениаминович Сахаров | Способ функционирования системы условного доступа для применения в компьютерных сетях и система для его осуществления |
| US8516344B2 (en) * | 2008-10-01 | 2013-08-20 | Lg Electronics Inc. | Symbol-level random network coded cooperation with hierarchical modulation in relay communication |
| EP2550778A4 (fr) | 2010-03-24 | 2017-06-21 | Thomson Licensing | Procédé et appareil de surveillance de la qualité de service dans un réseau |
| US8695060B2 (en) | 2011-10-10 | 2014-04-08 | Openpeak Inc. | System and method for creating secure applications |
| US20150113506A1 (en) * | 2013-10-18 | 2015-04-23 | Openpeak Inc. | Method and system for adaptive loading of application |
| US8938547B1 (en) | 2014-09-05 | 2015-01-20 | Openpeak Inc. | Method and system for data usage accounting in a computing device |
| US9100390B1 (en) | 2014-09-05 | 2015-08-04 | Openpeak Inc. | Method and system for enrolling and authenticating computing devices for data usage accounting |
| US9232013B1 (en) | 2014-09-05 | 2016-01-05 | Openpeak Inc. | Method and system for enabling data usage accounting |
| US9350818B2 (en) | 2014-09-05 | 2016-05-24 | Openpeak Inc. | Method and system for enabling data usage accounting for unreliable transport communication |
| US20160071040A1 (en) | 2014-09-05 | 2016-03-10 | Openpeak Inc. | Method and system for enabling data usage accounting through a relay |
| US9232078B1 (en) | 2015-03-16 | 2016-01-05 | Openpeak Inc. | Method and system for data usage accounting across multiple communication networks |
| KR20180099683A (ko) * | 2015-12-31 | 2018-09-05 | 사이버 2.0 (2015) 엘티디. | 컴퓨터 네트워크에서 트래픽 모니터링 |
| CN110731099B (zh) * | 2017-06-06 | 2023-05-23 | 瑞典爱立信有限公司 | 用于用户平面功能分配的技术 |
| CN109560945B (zh) * | 2017-09-25 | 2021-02-12 | 华为技术有限公司 | 业务服务质量的检测方法、设备及系统 |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5870474A (en) * | 1995-12-04 | 1999-02-09 | Scientific-Atlanta, Inc. | Method and apparatus for providing conditional access in connection-oriented, interactive networks with a multiplicity of service providers |
| FI100563B (fi) * | 1996-01-30 | 1997-12-31 | Nokia Oy Ab | Digitaalisten esitysobjektien salaus lähetyksessä ja tallennuksessa |
| US6304973B1 (en) * | 1998-08-06 | 2001-10-16 | Cryptek Secure Communications, Llc | Multi-level security network system |
| US7370348B1 (en) * | 1999-07-30 | 2008-05-06 | Intel Corporation | Technique and apparatus for processing cryptographic services of data in a network system |
| US20020009058A1 (en) * | 2000-04-14 | 2002-01-24 | Frank Kelly | System and method for performing auto-commissioning in a two-way satellite system |
-
2001
- 2001-04-19 FR FR0105318A patent/FR2823936B1/fr not_active Expired - Fee Related
-
2002
- 2002-04-18 EP EP20020730365 patent/EP1396135A1/fr not_active Withdrawn
- 2002-04-18 WO PCT/FR2002/001337 patent/WO2002087190A1/fr active Application Filing
- 2002-04-18 JP JP2002584572A patent/JP2004535704A/ja active Pending
- 2002-04-18 CA CA002444435A patent/CA2444435A1/fr not_active Abandoned
- 2002-04-18 KR KR10-2003-7013599A patent/KR20030092083A/ko not_active Application Discontinuation
- 2002-04-18 CN CNA028122666A patent/CN1518824A/zh active Pending
- 2002-04-18 US US10/474,687 patent/US20040128665A1/en not_active Abandoned
Also Published As
| Publication number | Publication date |
|---|---|
| WO2002087190A1 (fr) | 2002-10-31 |
| FR2823936A1 (fr) | 2002-10-25 |
| CN1518824A (zh) | 2004-08-04 |
| KR20030092083A (ko) | 2003-12-03 |
| JP2004535704A (ja) | 2004-11-25 |
| FR2823936B1 (fr) | 2003-05-30 |
| EP1396135A1 (fr) | 2004-03-10 |
| US20040128665A1 (en) | 2004-07-01 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA2444435A1 (fr) | Procede et systeme d'acces conditionnel a des services ip | |
| EP0528730B1 (fr) | Procédés d'émission et de réception de programmes personnalisés | |
| EP2055102B1 (fr) | Procédé de transmission d'une donnée complémentaire a un terminal de réception | |
| JP5575915B2 (ja) | Ｉｐｔｖのための階層型サービス再販機構 | |
| US20070168436A1 (en) | System and method for supplying electronic messages | |
| EP3053327B1 (fr) | Procédé de diffusion d'identifiants de sources multicast | |
| EP1687975B1 (fr) | Diffusion sécurisée et personnalisée de flux audiovisuels par un systeme hybride unicast/multicast | |
| EP1890493A1 (fr) | Méthode de révocation de modules de sécurité utilisés pour sécuriser des messages diffusés | |
| EP1470690A2 (fr) | Procede et dispositif de transmission de message de gestion de titre d'acces | |
| EP1461951A2 (fr) | Procede et systeme de transmission avec controle d acces de donnees numeriques embrouillees dans un reseau d echange de donnees | |
| EP1253745A2 (fr) | Procédé facilitant le téléchargement simultané d'un fichier multicast vers une pluralité d'utilisateurs | |
| EP2767060B1 (fr) | Passerelle, et procédé, programme d'ordinateur et moyens de stockage correspondants | |
| EP2273786A1 (fr) | Contrôle d'accès à un contenu numérique | |
| FR2812504A1 (fr) | Systeme de cryptage/decryptage "a la volee" pour la diffusion de donnees | |
| WO2003098870A2 (fr) | Procede de distribution de donnees avec controle d'acces | |
| EP1633144A1 (fr) | Procédé de gestion des conditions d accès à un flux vidéo par un routeur / DSLAM | |
| EP1142261B1 (fr) | Procede de transport de paquets entre une interface d'acces et un reseau partage | |
| FR2889902A1 (fr) | Procedes de transmission, d'encodage et de reception de donnees multimedia protegees par des cles de cryptage, signal, support de donnees, dispositif de restition et programmes correspondants | |
| EP2328316B1 (fr) | Controle d'accès à un contenu numérique | |
| EP1633143A1 (fr) | Procédé de gestion des conditions d'accès à un flux vidéo par un routeur / DSLAM, et routeur pour la mise en oeuvre de ce procédé | |
| EP2223524A1 (fr) | Procédé de conditionnement et de contrôle d'accès à des contenus en codage hiérarchique, processeur et émetteur pour ce procédé | |
| WO2005076527A1 (fr) | Procede et dispositif de distribution de flux numeriques multimedia |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| FZDE | Discontinued |