EP1396135A1 - Procede et systeme d'acces conditionnel a des services ip - Google Patents

Procede et systeme d'acces conditionnel a des services ip

Info

Publication number
EP1396135A1
EP1396135A1 EP20020730365 EP02730365A EP1396135A1 EP 1396135 A1 EP1396135 A1 EP 1396135A1 EP 20020730365 EP20020730365 EP 20020730365 EP 02730365 A EP02730365 A EP 02730365A EP 1396135 A1 EP1396135 A1 EP 1396135A1
Authority
EP
European Patent Office
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.)
Withdrawn
Application number
EP20020730365
Other languages
German (de)
English (en)
Inventor
Emmanuel Gouleau
No[L Fontaine
David Girault
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
France Telecom SA
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by France Telecom SA filed Critical France Telecom SA
Publication of EP1396135A1 publication Critical patent/EP1396135A1/fr
Withdrawn legal-status Critical Current

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]

Definitions

  • the present invention relates to the field of scrambling and controlling access to IP services.
  • the invention relates more particularly to a method and a system for transmitting / receiving information with access control through a network using the IP protocol as well as a device making it possible to implement the method.
  • This method can be used to control access to audiovisual streaming services over IP and to data broadcasting services broadcast by satellite over the Internet.
  • IPSEC protection does not require modification of the server or of the application software installed at the client.
  • the scrambling is generally applied to all traffic between the client and the server and not just to a specific service.
  • the IPSEC standard cannot be used if one wishes to carry out selective scrambling on specific services.
  • SSL Secure Socket Layer
  • This technique uses protocol identifiers and port numbers to distinguish protected data from unprotected data. For example, a hyperlink on the network will use this technique if the protocol identifier says "HTTPS" instead of "HTTP”.
  • HTTPS HyperText Transfer Protocol
  • Data protected by SSL generally navigates through a connection to port 443 of the TCP server. Also, if the server receives a connection to port 443, it applies SSL scrambling to this connection and transmits the IP data to the client. This procedure allows the client and the server to distinguish protected data from that which is not.
  • a drawback of this technique comes from its dependence on the TCP transport protocol used and therefore imposes the data format of this protocol on the data to be scrambled.
  • the object of the invention is to remedy the drawbacks of the prior art described above by means of a method making it possible to scramble services I? a generic way and to control access to these services by means of an access control device such as a memory card.
  • Another object of the invention is to overcome the constraints linked to the transport protocol.
  • Another aim is to scramble IP data whatever the application using this data, in particular in the following service configurations:
  • the data block is encapsulated in a UDP packet.
  • the data block is encapsulated directly in an IP datagram.
  • the scrambling step comprises the following phases:
  • the data block comprises:
  • the data block respects the following syntax: CAS_DATA_UNIT () ⁇
  • the sequence (Payload) respects the following syntax: payload () ⁇ data bytes n bytes padding bytes p bytes,
  • the header also includes a field (EDC) representing an error detection sequence.
  • EDC error detection sequence
  • UDP which is itself inserted into an IP datagram, in transmission, a source UDP port is allocated dynamically when the UDP link is opened.
  • the allocation of the destination UDP port number can be carried out statically (optional configuration data dedicated by a regulatory authority) or else dynamically by a signaling protocol between the scrambler and the descrambler.
  • the reception of IP / UDP datagrams by the end client comprises the following steps: - receiving the second IP datagram; - receive the UDP packet on the port, previously opened (static or dynamic port);
  • Extract the data from the first Destination datagram send the extracted packet to the destination application.
  • the reception of UDP datagrams by the end client comprises the following steps:
  • the transmitted IP services are audiovisual streams over IP.
  • the IP services transmitted are data transmitted by satellite via an IP network.
  • the data are transmitted through an IP network by a transmitter comprising means for associating with the IP datagrams a header comprising at least one datum identifying the access control means and an indication of the scrambling method used.
  • the transmitter according to the invention also comprises:
  • this transmitter comprises an IP data flow server, a gateway comprising an IP scrambler, an ECM generator, an ⁇ MM generator and a database.
  • the reception of the data transmitted through the network is carried out by a receiver comprising means for extracting the header from a scrambled datagram and means for activating at least one access condition or at least one secret key.
  • the scrambling and access control system in an IP type network comprises a transmitter and a receiver as described above.
  • the IP services scrambling and access control device comprises a man-machine interface intended to define the services to be scrambled and to enter the access conditions or secret keys.
  • the access control means comprise a memory card for transporting the secret key.
  • FIG. 1 schematically shows a data transmission / reception system with access control according to the invention
  • FIG. 2 schematically illustrates the steps of defining the structure of a datagram according to one invention
  • FIG. 4 schematically illustrates a first reception mode implemented in the method according to the invention
  • Figure 5 schematically illustrates a second reception mode implemented in the method according to the invention
  • FIG. 6 schematically shows a system of scrambling data in a point-to-point environment according to the invention.
  • FIG. 1 schematically illustrates a system in which several data processing and transmission equipment are interconnected in a local area network 2 (LAN) which is connected, via the internet network 3, to several clients 4.
  • LAN 2 includes an IP data flow server ⁇ , a gateway 8 comprising an IP scrambler, an ECM generator 12 (DVB access control message, Entitlement Control Message) EMM 14 (DVB access management message, Entitlement Management Message in English) and a database 16.
  • LAN 2 is connected to a Web server 17.
  • the WEB server 17 indicating the characteristics of the Application server (@IP_server, program_name , scrambling_active) is not necessarily on the same LAN 2.
  • the IP data delivered by the stream server 6 can be audio visual services requiring the possession of an access right recorded in a memory card held by authorized clients 4. These audio visual services are scrambled by the IP scrambler integrated into the gateway 8 before being transmitted over the internet network 3.
  • Each client 4 has equipment 18 comprising an access control device such as for example a memory card.
  • the gateway 8 is provided with an HMI man-machine interface program enabling it: - to define the services to be scrambled; - enter access conditions or secret keys.
  • the services to be scrambled are identified by a label to which corresponds a source IP address or a destination IP address depending on whether it is desired to scramble the data originating from a source and / or going to a destination.
  • the scrambling of the data results from the connection of the service identifier (Idservice), characterized by the source address (s) and / or destination (d) IP datagrams, and a scrambling key.
  • the renewal periodicity of this key is relatively low in systems not using a memory card (table I), and may be higher in systems implementing a card (table II). In these, it is called the control word.
  • obtaining the control word is subject to the possession of rights previously entered in the card.
  • the signage related to the implementation of the access control system using the memory card to restore the control words in the IP context covers the following services in order of priority: - data broadcasting services using the UDP / IP stack: IPSat (push, file transfer);
  • IP multipoint flow IP multipoint flow
  • UDP / IP stack videoconferencing or multipoint audioconferencing, audiovisual broadcasting
  • FIG. 2 schematically illustrates the steps for creating a datagram according to the invention.
  • the data to be transmitted 20 are first cut into packets 21 which can be of variable lengths.
  • IP 21 is then associated with an IP header 22 to constitute a first IP datagram 23.
  • IP is based on the following principle: - Scrambling of the first IP 23 datagram
  • This header 24 includes a discriminator 25 identifying the type of access control system implemented to scramble the IP datagram 23, and control data 27. - Concatenation of this header 24 and the IP datagram 23 to form a block of data 26; - Encapsulate this data block 26 in a UDP datagram.
  • IP-CAS IP-Conditional Access System
  • header_length representing the total length of the header 24
  • the header 24 can also include a field (EDC) representing our error detection sequence. According to the invention, if (payload_scrambling_control ⁇ 00), the header 24 (Access_control_header) further includes a field (payload_descrambling_way) specifying the descrambling mode of the content of the payload.
  • the header 24 also includes a field (ECM_CA_descriptor_flag) indicating the presence of at least one conditional access descriptor (ECM_CA_descriptor) in the header 24 of the datagram scrambled 23, and a field (ECM_flag) indicating, when its value is equal to 1, the presence of at least one ECM field () in the header of the scrambled datagram 23.
  • ECM_CA_descriptor_flag indicating the presence of at least one conditional access descriptor in the header 24 of the datagram scrambled 23.
  • the header 24 includes a field (Nb_ECM_CA_descriptor) indicating the number of blocks (ECM_CA_descr ⁇ ptor) present in this header 24 of the scrambled datagram 23.
  • the header 24 also includes a field (access_control_header_start_sequence) or making it possible to identify the start of the header, a field (vers ⁇ on_number) indicating the current version of the header 24, a field (serv ⁇ ce_ID) indicating the reference of the service used, a field (payload_type) indicating the type of data transmitted, and a field (RUFO) reserved for future use.
  • the header 24 also includes a field
  • the header 24 (Access_control_header) also includes:
  • IVOperator_ID_length indicating, when its value is other than zero, the presence and the length of the vector field for initializing the scrambler
  • the header 24 also includes a field (ECM_CA_descr ⁇ ptor_flag) indicating, when its value is equal to 1, the presence of at least one conditional access descriptor (ECM_CA_desc ⁇ ptor) in the header 24 of the scrambled datagram 23, a field ( RUF2) reserved for future use.
  • ECM_CA_descr ⁇ ptor_flag indicating, when its value is equal to 1, the presence of at least one conditional access descriptor (ECM_CA_desc ⁇ ptor) in the header 24 of the scrambled datagram 23, a field ( RUF2) reserved for future use.
  • the header 24 includes a field (NB_ECM) indicating the number of ECM in the header 24 of the scrambled datagram 23.
  • the header 24 includes a third field (RUF3) reserved for future use;
  • the access control message includes:
  • an ECM_ ⁇ ex pointer intended to differentiate several ECMs to select a particular ECM for descrambling
  • the access control message has the following format: ECM () ⁇
  • ECM_table 8 bits ⁇ where ECM_index represents the ECM associated with the conditional access descriptor, and
  • ECM_table represents the structure of ECM.
  • the ECM table includes: - an identification field (table_id)
  • ECM-length a field indicating the length of an ECM
  • table_id represents an 8-bit field that identifies the type of data contained in the table; - a field (descriptor_tag) indicating the start of an ECM conditional access descriptor;
  • ECM_CA descriptor_length indicating the length of an ECM descriptor
  • CA_system_ID representing an identifier of the access control system used
  • conditional access descriptor (ECM_CA_descriptor) has the following format:
  • ECM_mdex 8 bit for ( ⁇ 0; KN; ⁇ ++) ⁇ p ⁇ vate_data_bytes 8 bit
  • ⁇ and the algorithm type identifier includes: - a CI_tag identifier; - a Cl-length field indicating the length of the identifier; a CI_value field indicating the value of the Cl-tag identifier.
  • the algorithm type identifier scrambles this in the following format: TO ⁇
  • the service operator includes:
  • an identifier SOID_tag of the block allowing to describe the area of the service operator used in the smart card; - a SOID_length field indicating the length of said zone;
  • SOID_value represents a field identifying a service area used in the smart card.
  • FIG. 4 schematically illustrates the scrambling activated by the WEB server 17 - (step (c)) on the initiative of the client (step (a)).
  • an active daemon on the WEB server 17 sends an activation request to the IP scrambler (step (b)) on reception of an HTTP request (a) from the client on a link with the “scrambling to activate ”(keyword in the URL ht tp: // @ IP: port / scrambled_program / program_name,).
  • the scrambling scenario is as follows:
  • the flow server 6 sends IP datagrams 23 in point-to-point mode or in Multipoint mode.
  • the destination address of datagrams 23 is that of the client (point-to-point) or else a broadcast address (Multipoint).
  • the IP scrambler optionally filters the IP datagrams 23 whose origin address is that of the flow server 6 and maintains a scrambling session by destination address. This filter acts at the Ethernet level in the diagram in Figure 4. 3) The IP scrambler then concatenates the header 24 (access_control_header) to the IP datagram 23 which is scrambled in step 2 then sends this field on a UDP stack to the same destination address as the initial datagram.
  • the valuation of the UDP / IP tunnel fields in transmission is carried out according to the following mechanism:
  • the scrambler generates an IP datagram with the following information: •
  • the source IP address is the IP address of
  • This address is a public IP address.
  • the destination IP address is the destination address of the initial datagram.
  • the source UDP port is allocated dynamically when the UDP stack is opened.
  • the UDP port of the scrambled stream is not the same as the UDP port of the original stream in order to avoid loopback problems on the client computer.
  • the known ports are the ports of 0 and 1023;
  • the registered ports are those from 1024 to 49151;
  • the dynamically allocated ports are those from 49152 to 65535.
  • IP CAS IP address Translation
  • daunbler software 35 is installed on the client computer (Windows, Linux, MacOS,). Two implementations are envisaged, either the use of a Pseudo-driver 40, or the use of loopback in "raw” mode. 1 - Use of a pseudo-driver.
  • FIG. 5 illustrates this mode of implementation.
  • the data is received on the interface of the access provider 42 to the internet network 3 (ISP) and forwarded via the IP stack 44 of the client machine to the descrambler 35 awaiting UDP data on the specific port IP_CAS.
  • This descrambler 35 recovers data from the UDP datagram via the IP stack, extract the ⁇ d ⁇ sc ⁇ mmateur - access_control_header> header and descramble the original IP datagram.
  • ISP internet network 3
  • the descrambler 35 provides the IP datagram to the end client 4 awaiting data on the original destination port.
  • the network pseudo-driver 40 In order to transmit this IP datagram to the end customer (local to the machine), the network pseudo-driver 40 must be developed under the IP stack: - This pseudo-driver is awaiting data from the descrambler 35 and provides it to the IP stack.
  • the final application is waiting on its particular port and normally retrieves the data in clear after unencapsulating the original IP datagram by the IP / TCP or UDP stack.
  • This solution can be implemented on an operating system allowing the addition of a 2nd network driver under the IP stack of the machine.
  • the routing of the FAI 42 and pseudo-driver 40 drivers at the IP layer is done on an IP address specific to each network driver according to the following mechanism:
  • This mechanism allows the recovery of the original datagram 23 without modification, making the descrambling function completely independent of the client. final. It only uses the IP stack in UDP / TCP mode when receiving data.
  • the data is received on the FAI interface 42 and fed back via the IP stack 44 from the client machine to the descrambler 35 awaiting UDP data on the port specific IP_CAS.
  • the descrambler 35 recovers the data from the UDP datagram via the IP stack 44 extracts the header 24 ⁇ discriminator - access_control_header> and descrambles the original IP datagram 23.
  • the descrambler 35 supplies this IP datagram 23 to the end client awaiting data on the original destination port in UDP or in TCP.
  • the IP datagram 23 is re-transmitted in the FAI / IP stack 42 via the IP stack 44 passing to the destination IP address the loopback IP address of the machine (127.0.0.0). This re-transmission takes place in RAW mode because the re-transmitted data constitute a complete IP frame which must not be modified.
  • the loopback mechanism of the IP 44 stack therefore feeds the data without re-transmitting it.
  • the descrambler 35 is on standby on its particular port and normally recovers the data in the clear after decapsulating the IP datagram by the IP / TCP / UDP stack.
  • This solution can be implemented on an operating system allowing the use of RAW mode of the IP 44 stack in loopback on the transmitter side and is done according to the following mechanism:
  • this mechanism uses only the IP stack 44 in UDP / TCP mode when receiving data to pass them to the descrambler 35 as when transmitting data to re-transmit them to the final application.
  • FIG. 7 schematically represents a system for scrambling data in a point-to-point environment according to the invention.
  • This system includes a terminal of a user 4, a service provider ⁇ , an ECM generator 12, a database 16, a server for presenting the offer 64, an editor for access conditions 66, a RTSP 72 audiovisual control gateway, an internet service provider 74.
  • the following steps describe a user's access to a VOD service using a memory card.
  • the principle can be extended to other types of Point-to-Point services. Access begins with a subscriber authentication phase. This phase takes place just after the subscriber has connected to the Internet service provider 74.
  • the terminal of the user 4 goes up, its IP address, dynamically assigned by the access provider 74 at the time of the connection to the network, and the AU (unique address) of his card.
  • Phase 1 Presentation of the offer.
  • the user makes an HTTP request on a server presenting the offer 64.
  • the presentation of the page is optional and can be managed directly by the operator.
  • the page appears while at the request of the subscriber, when reloading rights for example.
  • Phase 2 presupposes that the user has selected a particular service (eg choice of a film in a VoD service).
  • a particular service eg choice of a film in a VoD service.
  • phase 2 The first to the browser. : phase 2; - The second to the scrambling system: phase 2 '.
  • the presentation server returns to the terminal in the HTTP response the complete URL of the film (ex: http: // served. Film-name.ram);
  • Phase 3 launch of the film player execution program
  • the RTSP server then opens a TCP session with the server concerned by the delivery of the film (here served ..).
  • Phase 5 launch of the broadcast
  • the stream server 6 then transmits the film in UDP / IP datagrams to the scrambling gateway with the source address, the server address and the destination address, the address of the final client.
  • the 0 ′ gateway gateway whose Point-to-Point filters are activated automatically as soon as Point-to-Point services are detected in base 16, can then scramble generically (on @ origin) or personalized (on @ recipient) ) or depending on the URL the descending data.
  • Phase 7 Closing a Point-to-Point session A Point-to-Point session can be closed by the scrambling gateway on time-out (no reception of packets from a given source or destination address for X seconds ).
  • the maximum point-to-point time-out value is specified when configuring the general parameters of the equipment.

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'é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 (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 œ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 nécessite pas la modification du serveur ou des logiciels applicatifs installés chez le client. Cependant, l' embrouillage est généralement appliqué à l'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 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 , la voie de retour n'est pas nécessaire, par exemple transmission par satellite (multicast en anglais) .
Par ailleurs, l'échange des clés permettant d'accéder aux contenus s'effectue par le biais 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é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 serveur reçoit une connexion au port 443, il applique 1' 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 I? αe 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 multipomt 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 ; - 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 deuxième datagramme IP a 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 autorise ;
- délivrer les données desembrouillé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' 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 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 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 ; - 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. 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' ΞMM 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 Dispositif d ' embrouillage et 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 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 1' invention ;
- la figure 3 illustre schématiquement un mode préféré de réalisation de l' embrouillage selon
1' invention ;
- la figure 4 illustre schématiquement- un premier mode de réception mis en œuvre dans le procédé selon 1' invention ; - la figure 5 illustre schématiquement un deuxième mode de réception mis en œuvre dans le procédé selon 1' 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 le réseau internet 3, à plusieurs clients 4. Le LAN 2 comporte un serveur β 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 le réseau 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. 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 n'utilisant 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
TABLEAU II
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 : - 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 œ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 ; - 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 ur.e séquence de décection d'erreurs. Selon l'invention, si (payload_scrambling_control≠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 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≠l) , l'entête 24 comporte un champ (Nb_ECM_CA_descriptor) indiquant le nombre de blocs (ECM_CA_descrιptor ) 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 (versιon_number) indiquant la version courante de l'entête 24, un champ (servιce_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é pour un usage futur.
L'entête 24 comporte par ailleurs un champ
(scramblιng_algoπthm_type) destiné à indiquer le type d'algorithme utilisé pour embrouiller le datagramme, et un cna p 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_paddιng_sιze) 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 1' 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 en outre un champ (ECM_CA_descrιptor_flag) indiquant, quand sa valeur est égale à 1, la présence d'au moins un descripteur d'accès conditionnel (ECM_CA_descπptor ) 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_descrιptor_versιon__number) indiquant la version du bloc (ECM_CA_descriptor) . Si (EMM_CA__descπptor_flag = 1), l'entête 24 comporte un champ (EMM_CA_descrιptor_vers on_number ) indiquant la version du bloc (EMM_CA_descrιptor ) et un bloc αe données (ΞMM-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_descramblmg_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_ιndex destiné a 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_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 : - 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 ( ) ( table_id = 0x80 ou 0x81 ' 8 bits
NOTJSED 4 bits
ECM_length -12 bits
NOTJJSED 8 bits
For (i = G ; i<M ; i++) { ECM_data_bytes 8 bits
} où, table_id représente un 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 le format suivant :
ECM CA descriptor ( ) { Descrιptor_tag = 0x09 8 bits
ECM_CA_descπptor_length 8 bits
CA_system_ID 16 bits
ECM_mdex 8 bits for (ι = 0 ; KN ; ι++) { pπvate_data_bytes 8 bits
} et l'identificateur du type d'algorithme comporte : - un identificateur CI_tag ; - un champ Cl-length indiquant la longueur de l'identificateur ; un champ CI_value indiquant la valeur de l'identificateur Cl-tag.
L'identificateur du type d'algorithme d' embrouille ce prεse^ta le format suivant : TO {
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 : SOIDO { 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 1' 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 h t tp : //@IP : port/prog_embrouillé/nom_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. 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 β 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 «câblées » dans une table sur 1' 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' 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 : • L'adresse IP source est l'adresse IP de
1' 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. 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 enregistres 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 installe 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 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 <dιscπmmateur - access_control_header> et désembrouille le datagramme IP d'origine.
Le désembrouilleur 35 fournit le datagramme IP au 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 : - Ce pseudo-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écupère normalement les données en 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'exploitation permettant l'ajout d'un 2ème driver réseau sous la pile IP de la machine. Le routage 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ésembrouille au pseudo-driver,
(4) récupé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 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 le 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' 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 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, (2) récupération du datagramme IP embrouillé,
(3) passage du datagramme IP d'origine désembrouille (avec l'adresse IP de destination remplacée par 127.0.0.0) au pseudo-driver en mode RAW et loopback,
(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 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 β, 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 a 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 façon dynamique par le fournisseur d'accès 74 au moment de la connexion 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 acoaraî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 I'URL complète du film (ex : http : //servi . 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" . Le player se connecte à I'URL http: //seryl/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 12 redirigean t la requête RSTP vers le serveur de fl ux, le plus adapté, la passerelle de commande 12 et le serveur de fl ux 6 sont éven tuellemen t 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 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 0' emorouillage dont les filtres Point-à-Point sont activés de façon automatique dès la 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 time-out Point-à-Point est précisée lors de la configuration des paramètres généraux de l'équipement. ANNEXE αccess_coπtrol_heαder()j αccess_coπtroLheαder_s αrt_sequence 32 bits heσder_length 16 bits version_πumber S bits service_ID 16 bits pαyloαd_type a bits pαyloαd_5crαmbling_coπtrol 2 oirs
RUF 0 0 ûirs if (pαyloαd_scrαmbliπg_control !=00)| scrαmbliπg_αlgorithm_tγpβ 3 bits pαyloαd_pαdding_size 8 bits pαyloαd-dsscrGmbling_wαy 3 bits cleαr_pαyloαd_CRC32 32 bits
IVoperαtor_ID_length δ bits
IVoperαtor_ID_vαlue IVoperαtorJDJeπgth* S bits
RUF 1 2 bits if(pcγlo d_desc α.τbϋr.ç_,vcy==001)|
ECM_CA_descriptor_flαg 1 bit
EM _CA_descriptor_f!cg 1 bit
1
EC Iαg I bit
RUF 2 5 bits if (ΞCW_CA_descrîptor_f lαg = = 1 )^ Nb_ECW_CA_descriptor δ bits EC _CA_descripfor_version_πumber δ DITS for (;=0;i<n;i++)|
ECM_CA_descriptor()
if (ECM_CΛ_descriptor_f!σç==1 )| δ bits
E M_CA_descriptor_γersion_πumber EMM_CA_descriptor()
if (EC JIαg==1)i NB ECM δ bits
TOΓ i=0;i;i ++)| ECM()
if (pαyloαd_descrαmbling_wαy==010)j
RUF 3 16 bits
l EDC δ bits

Claims

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 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 .
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 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).
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.
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ése orouillage des informations (20) .
11. Procédé selon la revendication 10, caractérisé en ce que, si (payload_descrambling_way ooi: 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=l) , 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 ΞCM_CA_descriptor ) dans l'entête du datagramme e crou Iié (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 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) .
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_ιndex) .
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 (Cl-length) indiquant la longueur de l'identificateur (CI_tag) ;
- un champ (CI_value) indiquant la valeur de l'identificateur (Cl-tag) .
25. Procédé selon l'une des revendications précédentes, caractérise 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 (S0ID_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
IF/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ésembrouille à 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.
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 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.
EP20020730365 2001-04-19 2002-04-18 Procede et systeme d'acces conditionnel a des services ip Withdrawn EP1396135A1 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
FR0105318 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
EP1396135A1 true EP1396135A1 (fr) 2004-03-10

Family

ID=8862485

Family Applications (1)

Application Number Title Priority Date Filing Date
EP20020730365 Withdrawn EP1396135A1 (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)

* Cited by examiner, † Cited by third party
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 Олег Вениаминович Сахаров Способ функционирования системы условного доступа для применения в компьютерных сетях и система для его осуществления
WO2010039013A2 (fr) * 2008-10-01 2010-04-08 Lg Electronics Inc. Coopération codée par réseau aléatoire au niveau de symboles avec une modulation hiérarchique dans une communication de relais
CN102804713B (zh) 2010-03-24 2016-06-22 汤姆森特许公司 用于监测网络服务质量的方法和设备
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
US20160071040A1 (en) 2014-09-05 2016-03-10 Openpeak Inc. Method and system for enabling data usage accounting through a relay
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
US9232078B1 (en) 2015-03-16 2016-01-05 Openpeak Inc. Method and system for data usage accounting across multiple communication networks
WO2017115356A1 (fr) * 2015-12-31 2017-07-06 Cyber 2.0 (2015) Ltd. Surveillance du trafic dans un réseau informatique
WO2018224126A1 (fr) * 2017-06-06 2018-12-13 Telefonaktiebolaget Lm Ericsson (Publ) Technique d'attribution de fonction de plan utilisateur
CN109560945B (zh) * 2017-09-25 2021-02-12 华为技术有限公司 业务服务质量的检测方法、设备及系统

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001010095A2 (fr) * 1999-07-30 2001-02-08 Intel Corporation Protection de communications

Family Cites Families (4)

* Cited by examiner, † Cited by third party
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
US20020009058A1 (en) * 2000-04-14 2002-01-24 Frank Kelly System and method for performing auto-commissioning in a two-way satellite system

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001010095A2 (fr) * 1999-07-30 2001-02-08 Intel Corporation Protection de communications

Also Published As

Publication number Publication date
JP2004535704A (ja) 2004-11-25
CN1518824A (zh) 2004-08-04
FR2823936A1 (fr) 2002-10-25
CA2444435A1 (fr) 2002-10-31
US20040128665A1 (en) 2004-07-01
WO2002087190A1 (fr) 2002-10-31
FR2823936B1 (fr) 2003-05-30
KR20030092083A (ko) 2003-12-03

Similar Documents

Publication Publication Date Title
EP1396135A1 (fr) Procede et systeme d&#39;acces conditionnel a des services ip
EP0528730B1 (fr) Procédés d&#39;émission et de réception de programmes personnalisés
US7092999B2 (en) Data broadcast network for congestion-free internet access
CA2423024C (fr) Systeme de telecommunication, notamment de type ip, et equipements pour un tel systeme
EP2055102B1 (fr) Procédé de transmission d&#39;une donnée complémentaire a un terminal de réception
JP4813006B2 (ja) 安全なパケット・ベースのデータ・ブロードキャスティング・アーキテクチャ
EP1440550B1 (fr) Procedes de multidiffusion d&#39;un contenu
EP1687975B1 (fr) Diffusion sécurisée et personnalisée de flux audiovisuels par un systeme hybride unicast/multicast
WO2001098920A1 (fr) Procede et appareil de distribution de programmes video au moyen d&#39;une mise en antememoire partielle
FR2825222A1 (fr) Dispositif et procedes de transmission et de mise en oeuvre d&#39;instructions de controle pour acces a des fonctionnalites d&#39;execution
WO2003039153A2 (fr) Procede et systeme de transmission avec controle d&#39;acces
FR2835371A1 (fr) Procede et dispositif de transmission de message de gestion de titre d&#39;acces
HUE032334T2 (en) Transmission of messages via mobile phone network to digital multimedia network
FR2933564A1 (fr) Procede d&#39;embrouillage et desembrouillage pour le transport de flux de donnees audio video mpeg2
EP1506661A2 (fr) Procede de distribution de donnees avec controle d acces
WO2016116681A1 (fr) Procédé de diffusion d&#39;un contenu multimédia protégé
WO2004082286A1 (fr) Systeme de television a peage, procede de diffusion de programmes audiovisuels brouilles, decodeur et carte a puce mettant en oeuvre ce procede
WO2002011443A1 (fr) Systeme de cryptage/decryptage &#39;a la volee&#39; pour la diffusion de donnees
EP2016735A1 (fr) Procedes de diffusion et de reception de programmes multimedias embrouilles, terminal et tete de reseau pour ces procedes
EP2223524A1 (fr) Procédé de conditionnement et de contrôle d&#39;accès à des contenus en codage hiérarchique, processeur et émetteur pour ce procédé
FR2889902A1 (fr) Procedes de transmission, d&#39;encodage et de reception de donnees multimedia protegees par des cles de cryptage, signal, support de donnees, dispositif de restition et programmes correspondants
FR2877179A1 (fr) Procede de transmission d&#39;un flux video dans un reseau de telecommunications mobiles a debit restreint
Simpson Audio and Video over IP Networks and Internet Broadcasting
JP2007184873A (ja) 伝送システム、送信装置、及び受信装置
EP2265013A1 (fr) Transmission de contenu vers un équipement client comportant au moins un module de décodage et un module de sécurité

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20031009

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE TR

AX Request for extension of the european patent

Extension state: AL LT LV MK RO SI

RIN1 Information on inventor provided before grant (corrected)

Inventor name: GIRAULT, DAVID

Inventor name: FONTAINE, NO(L

Inventor name: GOULEAU, EMMANUEL

17Q First examination report despatched

Effective date: 20070820

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20091103