FR3062012A1 - Procedes et dispositifs de delegation de diffusion de contenus chiffres - Google Patents

Procedes et dispositifs de delegation de diffusion de contenus chiffres Download PDF

Info

Publication number
FR3062012A1
FR3062012A1 FR1750324A FR1750324A FR3062012A1 FR 3062012 A1 FR3062012 A1 FR 3062012A1 FR 1750324 A FR1750324 A FR 1750324A FR 1750324 A FR1750324 A FR 1750324A FR 3062012 A1 FR3062012 A1 FR 3062012A1
Authority
FR
France
Prior art keywords
server
content
delivery
request
delegation
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.)
Pending
Application number
FR1750324A
Other languages
English (en)
Inventor
Emile Stephan
Frederic Fieau
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
Orange 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 Orange SA filed Critical Orange SA
Priority to FR1750324A priority Critical patent/FR3062012A1/fr
Priority to US16/478,350 priority patent/US11258770B2/en
Priority to EP18703059.8A priority patent/EP3568966B1/fr
Priority to PCT/FR2018/050106 priority patent/WO2018130797A1/fr
Publication of FR3062012A1 publication Critical patent/FR3062012A1/fr
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/462—Content or additional data management, e.g. creating a master electronic program guide from data received from the Internet and a Head-end, controlling the complexity of a video stream by scaling the resolution or bit-rate based on the client capabilities
    • H04N21/4627—Rights management associated to the content
    • 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
    • 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/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • 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/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0884—Network architectures or network communication protocols for network security for authentication of entities by delegation of authentication, e.g. a proxy authenticates an entity to be authenticated on behalf of this entity vis-à-vis an authentication entity
    • 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/16—Implementing security features at a particular protocol layer
    • H04L63/166—Implementing security features at a particular protocol layer at the transport layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • 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/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/326—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the transport layer [OSI layer 4]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3265—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate chains, trees or paths; Hierarchical trust model

Abstract

L'invention concerne un procédé de demande de preuve de délégation pour la livraison d'un contenu à un terminal client (UA) au travers d'une connexion chiffrée, le contenu étant référencé sur un serveur (CSP) dit serveur de contenu, vers lequel le terminal client a émis une requête (E01) pour obtenir le contenu, le serveur de contenu ayant délégué la livraison dudit contenu à un serveur dit serveur primaire de livraison (uCDN), le procédé étant mis en œuvre par un serveur de livraison dit serveur secondaire de livraison (dCDN), auquel le serveur primaire de livraison a délégué la livraison dudit contenu, et comprenant les étapes suivantes : • réception (G01) d'une demande d'établissement d'une connexion chiffrée, en provenance du terminal client, comprenant un identifiant du serveur de contenu, • émission (G03) d'une demande de preuve de délégation de livraison, à destination du serveur de contenu, • réception (G06) d'un message en provenance du serveur de contenu, comprenant une clé de chiffrement, • émission (G07) d'une réponse d'établissement d'une connexion chiffrée, à destination du terminal client, • établissement (G09) de la connexion chiffrée avec le terminal client à l'aide de la clé de chiffrement.

Description

Titulaire(s) :
ORANGE Société anonyme.
O Demande(s) d’extension :
® Mandataire(s) : ORANGE/IMT/OLPS/IPL/PAT.
® PROCEDES ET DISPOSITIFS DE DELEGATION DE DIFFUSION DE CONTENUS CHIFFRES.
FR 3 062 012 - A1 (® L'invention concerne un procédé de demande de preuve de délégation pour la livraison d'un contenu à un terminal client (UA) au travers d'une connexion chiffrée, le contenu étant référencé sur un serveur (CSP) dit serveur de contenu, vers lequel le terminal client a émis une requête (E01 ) pour obtenir le contenu, le serveur de contenu ayant délégué la livraison dudit contenu à un serveur dit serveur primaire de livraison (uCDN), le procédé étant mis en oeuvre par un serveur de livraison dit serveur secondaire de livraison (dCDN), auquel le serveur primaire de livraison a délégué la livraison dudit contenu, et comprenant les étapes suivantes:
réception (G01 ) d'une demande d'établissement d'une connexion chiffrée, en provenance du terminal client, comprenant un identifiant du serveur de contenu, émission (G03) d'une demande de preuve de délégation de livraison, à destination du serveur de contenu, réception (G06) d'un message en provenance du serveur de contenu, comprenant une clé de chiffrement, émission (G07) d'une réponse d'établissement d'une connexion chiffrée, à destination du terminal client, établissement (G09) de la connexion chiffrée avec le terminal client à l'aide de la clé de chiffrement.
Figure FR3062012A1_D0001
Figure FR3062012A1_D0002
Procédés et dispositifs de délégation de diffusion de contenus chiffrés
1. Domaine de l'invention
La demande d’invention se situe dans le domaine des réseaux de distribution de contenus, et plus particulièrement pour les contenus chiffrés.
2. Etat de la technique antérieure
Une part de plus en plus grande du trafic Internet est transportée sur le protocole TLS (Transport Layer Security, sécurité de la couche de transport, en anglais), un protocole standardisé par l'IETF dans le RFC 5346 et permettant de sécuriser les échanges entre un client et un serveur.
TLS permet d'authentifier le serveur ou le client, de chiffrer le contenu des échanges entre eux et d'en vérifier l'intégrité.
Lorsqu'un utilisateur souhaite consommer un contenu sur Internet avec son terminal client, par exemple par le biais d’une application telle qu'un navigateur (browser en anglais, aussi appelé user agent), une requête est émise à un serveur d'un fournisseur de contenu. Le plus souvent, ce fournisseur de contenu délègue la livraison du contenu à un serveur dit de cache, choisi en fonction de plusieurs critères, comme par exemple la localisation du terminal du client et les termes du contrat entre le fournisseur de contenu et l'opérateur de l'autre serveur, lorsque ce contrat existe. La requête initiale est redirigée par le serveur du fournisseur de contenu vers le serveur de cache de façon transparente pour le terminal client. Ceci peut être fait à l'aide d'une redirection https car une telle redirection permet au serveur de cache de livrer le contenu tout en affichant le nom de domaine du fournisseur de contenu, tout en utilisant le matériel cryptographique associé à l'identité du fournisseur de contenu. Ce matériel cryptographique peut comprendre entre autre une clé publique et une clé privée.
Lorsque ce serveur de cache, aussi appelé premier serveur délégué, délègue lui-même l'opération de livraison du contenu à un second serveur, dit second serveur délégué, la continuité de la sécurisation est interrompue. Le terminal client, requérant le contenu auprès du serveur du fournisseur de contenu, est directement ou indirectement redirigé vers le second serveur délégué, celui-ci ne peut pas satisfaire la requête car il ne possède pas le matériel cryptographique adéquat.
Un des buts de l'invention est de remédier à ces inconvénients de l'état de la technique.
3. Exposé de l'invention
L'invention améliore la situation à l'aide d'un procédé de demande de preuve de délégation pour la livraison d'un contenu à un terminal client au travers d'une connexion chiffrée, le contenu étant référencé sur un serveur dit serveur de contenu, vers lequel le terminal client a émis une requête pour obtenir le contenu, le serveur de contenu ayant délégué la livraison dudit contenu à un serveur dit serveur primaire de livraison, le procédé étant mis en œuvre par un serveur de livraison dit serveur secondaire de livraison, auquel le serveur primaire de livraison a délégué la livraison dudit contenu, et comprenant les étapes suivantes :
• réception d'une demande d'établissement d'une connexion chiffrée, en provenance du terminal client, comprenant un identifiant du serveur de contenu, • émission d'une demande de preuve de délégation de livraison, à destination du serveur de contenu, • réception d'un message en provenance du serveur de contenu, comprenant une clé de chiffrement, • émission d'une réponse d'établissement d'une connexion chiffrée, à destination du terminal client, • établissement de la connexion chiffrée avec le terminal client à l'aide de la clé de chiffrement.
Selon la technique antérieure, un terminal demandant un contenu à un serveur de contenu, s'il est redirigé vers un serveur secondaire de livraison n'ayant pas de relation préalable avec le serveur de contenu, la connexion pour la livraison effective du contenu ne peut pas être chiffrée de façon certifiée par le serveur de contenu.
Grâce au procédé de demande de preuve de délégation, le serveur secondaire obtient le matériel cryptographique nécessaire à l'établissement de la connexion chiffrée. La connexion est perçue par le terminal comme si elle était établie avec un serveur du même domaine que le serveur de contenu, car le chiffrement est effectué à l'aide d'une clé obtenue auprès du serveur de contenu, qui est la même que celle que le terminal a nécessairement obtenu lorsqu'il a émis sa requête initiale vers le serveur de contenu.
Selon un aspect de l'invention, le procédé de demande de preuve de délégation comprend en outre les étapes suivantes :
• obtention du contenu auprès du serveur de contenu, • livraison du contenu au terminal client au travers de la connexion chiffrée.
Le serveur secondaire obtient le contenu auprès du serveur de contenu comme s'il était le serveur primaire, et la livraison du contenu peut se faire au travers de la connexion chiffrée par le serveur secondaire de livraison.
Selon un aspect de l'invention, le procédé de demande de preuve de délégation comprend les étapes suivantes, préalablement à l'étape de réception du message comprenant la clé de chiffrement :
• réception d'au moins une instruction relative à une capacité à livrer le contenu, en provenance du serveur de contenu, • exécution de l'instruction.
Avantageusement, le serveur de contenu peut tester les capacités du serveur secondaire de livraison, en lui envoyant un challenge file comprenant des instructions spécifiques, correspondant aux données de service. Les données de service comprennent une ou plusieurs instructions destinées à permettre la livraison du contenu.
Selon un aspect de l'invention, la demande de certification comprend une information relative aux capacités de livraison du serveur secondaire de livraison.
Grâce à cet aspect, le serveur secondaire permet au serveur de contenu de déterminer si le serveur secondaire est en mesure de livrer le contenu demandé de façon satisfaisante. Le serveur secondaire peut avoir préalablement obtenu du serveur primaire le même type d'information, ce qui lui permet d'adapter l'information aux attentes du serveur de contenu.
L'invention concerne aussi un procédé de délégation pour la livraison d'un contenu à un terminal client au travers d'une connexion chiffrée, le contenu étant référencé sur un serveur dit serveur de contenu vers lequel le terminal client a émis une requête pour obtenir le contenu, le serveur de contenu ayant délégué la livraison dudit contenu à un serveur dit serveur primaire de livraison, le serveur primaire de livraison ayant délégué la livraison dudit contenu à un serveur dit serveur secondaire de livraison, le procédé étant mis en oeuvre par le serveur de contenu, et comprenant les étapes suivantes :
• réception d'une demande de preuve de délégation, en provenance du serveur secondaire de livraison, • analyse de la demande, • en fonction du résultat de l'analyse, émission d'une réponse comprenant une clé de chiffrement associée au serveur de contenu.
Grâce au procédé de délégation, si le terminal est redirigé vers un serveur secondaire de livraison n'ayant pas de relation préalable avec le serveur de contenu, la livraison du contenu peut se faire au travers d'une connexion chiffrée à l'aide de la clé obtenue, car c'est la même que le terminal a nécessairement obtenu lorsqu'il a émis sa requête initiale vers le serveur de contenu.
Selon un aspect de l'invention, l'étape d'analyse comprend les étapes suivantes :
• émission d'au moins une instruction relative à une capacité à livrer le contenu, à destination du serveur secondaire de livraison, • vérification de l'exécution de l'instruction.
Avantageusement, le serveur de contenu profite d'une possibilité donnée par le protocole CSR, qui est de tester les capacités du serveur demandeur, en l'occurrence les capacités du serveur secondaire de livraison, en lui envoyant un challenge file comprenant des instructions spécifiques. De plus, ce challenge file comprend une ou des instructions destinées à tester la capacité du serveur secondaire à livrer le contenu.
Selon un aspect de l'invention, la réponse n'est pas émise si l'exécution de l'instruction n'est pas vérifiée après expiration d'une durée déterminée par le serveur de contenu.
Avantageusement, le serveur de contenu n'envoie pas la preuve de délégation demandée au serveur secondaire s'il n'est pas capable de livrer le contenu de façon satisfaisante. En conséquence, le serveur de contenu interrompt la communication avec le serveur secondaire qui ne pourra pas livrer le contenu au terminal.
Selon un aspect de l'invention, la réponse est émise avec une fausse clé si l'exécution de l'instruction n'est pas vérifiée après expiration d'une durée déterminée par le serveur de contenu, ou si le serveur secondaire de livraison n'est pas authentifié par une autorité de certification.
Si le serveur secondaire de livraison n'est pas capable d'exécuter une instruction requise pour la bonne livraison du contenu, ou s'il ne s'est pas identifié auprès du serveur de contenu à l'aide d'un certificat émanant d'une autorité reconnue, il est probable qu'il n'est pas légitime ou pas configuré pour livrer le contenu au terminal. Cependant, le serveur de contenu réagit comme si la demande du serveur secondaire de livraison était légitime. Ainsi, la connexion avec le serveur secondaire est maintenue assez longtemps, ce qui permet par exemple de localiser ce serveur à partir de son adresse IP, et d'engager une éventuelle action visant à neutraliser ou reconfigurer le serveur secondaire.
Selon un aspect de l'invention, la demande de preuve de délégation est un message de type Certificate Signing Request.
Selon la technique antérieure, une requête CSR (Certificate Signing Request, ou requête de signature de certificat, en anglais) ne peut être reçue que par un tiers de confiance largement reconnu, appelé autorité de certification, permettant d'authentifier l'identité du demandeur. Une telle autorité de certification est utilisée par exemple pour sécuriser des communications numériques via le protocole TLS.
Avantageusement, le même format de requête est utilisé entre deux serveurs, c’est-à-dire entre le serveur secondaire de livraison et le serveur de contenu. Ainsi, l'invention peut être exécutée avec un minimum de modification d'un protocole existant.
L'invention concerne encore un dispositif de demande de preuve de délégation pour la livraison d'un contenu à un terminal client au travers d'une connexion chiffrée, le contenu étant référencé sur un serveur dit serveur de contenu, vers lequel le terminal client a émis une requête pour obtenir le contenu, le serveur de contenu ayant délégué la livraison dudit contenu à un serveur dit serveur primaire de livraison, le serveur primaire de livraison ayant délégué la livraison dudit contenu à un serveur de livraison dit serveur secondaire de livraison, le dispositif comprenant une machine de calcul reprogrammable ou une machine de calcul dédiée, apte à et configurée pour :
• recevoir une demande d'établissement d'une connexion chiffrée, en provenance du terminal client, comprenant un identifiant du serveur de contenu, • émettre une demande de preuve de délégation de livraison, à destination du serveur de contenu, • recevoir un message en provenance du serveur de contenu, comprenant une clé de chiffrement, • émettre une réponse d'établissement d'une connexion chiffrée, à destination du terminal client, • établir la connexion chiffrée avec le terminal client à l'aide de la clé de chiffrement.
Ce dispositif de demande de preuve de délégation, apte à mettre en œuvre dans tous ses modes de réalisation le procédé de demande de preuve de délégation qui vient d'être décrit, est destiné à être mis en œuvre dans un serveur de diffusion de contenu.
L'invention concerne aussi un dispositif de délégation pour la livraison d'un contenu à un terminal client au travers d'une connexion chiffrée, le contenu étant référencé sur un serveur dit serveur de contenu vers lequel le terminal client a émis une requête pour obtenir le contenu, le serveur de contenu ayant délégué la livraison dudit contenu à un serveur dit serveur primaire de livraison, le serveur primaire de livraison ayant délégué la livraison dudit contenu à un serveur dit serveur secondaire de livraison, le dispositif comprenant une machine de calcul reprogrammable ou une machine de calcul dédiée, apte à et configurée pour :
• recevoir une demande de preuve de délégation, en provenance du serveur secondaire de livraison, • analyser la demande, • en fonction du résultat de l'analyse, émettre une réponse comprenant une clé de chiffrement associée au serveur de contenu.
Ce dispositif de de délégation, apte à mettre en œuvre dans tous ses modes de réalisation le procédé de délégation qui vient d'être décrit, est destiné à être mis en œuvre dans un serveur de référencement de contenu.
L'invention concerne aussi un système de délégation de diffusion de contenus chiffrés, comprenant un serveur de contenu, un serveur primaire de livraison, un serveur secondaire de livraison, et un terminal client, le serveur de contenu comprenant un dispositif de délégation tel que celui qui vient d'être décrit, le serveur secondaire de livraison comprenant un dispositif de demande de preuve de délégation tel que celui qui vient d'être décrit.
L'invention vise enfin :
• un programme d'ordinateur comprenant des instructions pour la mise en oeuvre des étapes du procédé de demande de preuve de délégation qui vient d'être décrit, lorsque ce programme est exécuté par un processeur, ainsi qu'un support d'informations lisible par un serveur de diffusion de contenu, et comportant des instructions de ce programme d'ordinateur, • un programme d'ordinateur comprenant des instructions pour la mise en oeuvre des étapes du procédé de délégation qui vient d'être décrit, lorsque ce programme est exécuté par un processeur, ainsi qu'un support d'informations lisible par un serveur de référencement de contenu, et comportant des instructions de ce programme d'ordinateur.
Ces programmes peuvent utiliser n’importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n’importe quelle autre forme souhaitable.
Les supports d'informations peuvent être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, un tel support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy dise) ou un disque dur.
D'autre part, un tel support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Un programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.
Alternativement, un support d'informations selon l'invention peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution des procédés en question.
4. Présentation des figures
D'autres avantages et caractéristiques de l'invention apparaîtront plus clairement à la lecture de la description suivante d'un mode de réalisation particulier de l'invention, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels :
• la figure 1 illustre une configuration réseau situant les entités impliquées dans la technique décrite, • la figure 2 présente un exemple d'enchaînement et de mise en oeuvre des étapes du procédé de demande de preuve de délégation et du procédé de délégation, selon un aspect de l'invention, • la figure 3 présente un exemple de structure d'un dispositif de demande de preuve de délégation, selon un aspect de l'invention, • la figure 4 présente un exemple de structure d'un dispositif de délégation, selon un aspect de l'invention.
5. Description détaillée d'au moins un mode de réalisation de l'invention
Dans la suite de la description, on présente des exemples de plusieurs modes de réalisation de l'invention se basant sur les protocoles TLS et https, mais l'invention peut se baser sur d'autres protocoles, tel que par exemple les protocoles HTTP1.1, SPDY, HTTP2, SCTP, DTLS, COAP et QUIC.
On décrit maintenant, en relation avec la figure 1, une configuration réseau situant les entités impliquées dans la technique décrite. Plus particulièrement, les entités suivantes sont illustrées :
• un serveur CSP d’un fournisseur de contenu référençant différents contenus (par exemple du contenu multimédia, du type comprenant des sons, des images ou des vidéos, ou des fichiers exécutables) destinés à être distribués à des terminaux clients d’utilisateurs finaux ;
• un terminal client UA, par exemple un ordinateur, un smartphone d’un utilisateur, cherchant à obtenir un contenu auprès du fournisseur de contenu, un tel terminal client UA pouvant embarquer un ou plusieurs agents clients (User Agent en anglais) du type http (pour HyperText Transfer Protocol en anglais) ou HTTPS (pour HyperText Transfer Protocol Secure en anglais) ou encore du type navigateur Internet ;
• un serveur de livraison de contenu uCDN auquel le serveur CSP du fournisseur de contenu a délégué la livraison du contenu en question et qui est connu du serveur CSP du fournisseur de contenu à l’aide d’un nom de domaine ;
• un secondaire de livraison de contenu dCDN auquel le primaire de livraison de contenu uCDN a potentiellement délégué la livraison du contenu recherché par l’utilisateur du terminal client UA dans un contexte de double délégation. ;
• un serveur de résolution de nom de domaine DNS permettant d’associer un nom de domaine à une adresse réseau ;
• un serveur CA d’une autorité de certification permettant de délivrer des certificats, par exemple selon le protocole HTTPS (pour « HyperText Transfer Protocol Secure » en anglais), aux serveurs en question.
Les différentes entités présentées ci-dessus sont alors connectées entre elles via un réseau 100 de télécommunications pour la transmission de données, par exemple basé sur un protocole internet.
Dans certains modes de réalisation, un serveur de résolution de nom de domaine local LDNS fait appel à un serveur DNS central.
Dans certains modes de réalisation, plusieurs serveurs CA d’autorités de certification sont utilisés, chaque serveur pouvant faire appel à un serveur CA différent.
Dans d’autres modes de réalisation, les serveurs de livraison uCDN et dCDN peuvent être regroupés dans une seule et même entité matérielle.
Dans encore d’autres modes de réalisation, davantage de serveurs de livraison sont présents, par exemple dans un contexte de délégations en cascade.
La figure 2 présente un exemple d'enchainement et de mise en œuvre des étapes du procédé de demande de preuve de délégation et du procédé de délégation, selon un aspect de l'invention.
Un utilisateur d'un terminal UA souhaite consommer un contenu multimédia
MMContent, référencé par un fournisseur de contenu, dont il connaît ou a obtenu l'identité d'une façon quelconque.
Dans une phase initiale non illustrée, par exemple à l'aide d'un moteur de recherche et une recherche à partir d'un nom du contenu ou à partir du nom du fournisseur de contenu, le terminal UA obtient le nom de domaine d'un serveur CSP associé au fournisseur de contenu, sur lequel est référencé le contenu MMContent. Cette adresse est par exemple sous forme d'url (Uniform Resource Locator, ou localisateur uniforme de ressource, en anglais), telle que csp.com.
Lors d'une étape E01, connue, à l'aide d'une application spécifique ou d'un navigateur générique, le terminal UA émet une requête pour obtenir le contenu MMContent. Par souci de simplicité le terme terminal est utilisé dans ce document, mais ce terme représente une telle application ou un tel navigateur (appelé browser en anglais), installée ou installé sur le terminal.
Cette requête pour obtenir le contenu est par exemple une requête http utilisant le protocole https, telle que:
http GET https://csp.com/MMContent
Cette requête déclenche une procédure d'établissement d'un tunnel sécurisé TLS entre le terminal UA et le serveur CSP. Cette procédure comprend l’envoi d’un message TLS ClientHello par l’UA. Le serveur CSP émet en réponse vers le terminal UA un message ServerHello comprenant du matériel cryptographique comme par exemple une clé publique à laquelle est associée une clé privée conservée par l’administrateur du domaine CSP. Ce couple de clés est en général attaché à un certificat d’un nom de domaine du serveur CSP, que le serveur CSP a obtenu après d'une autorité de certification quelconque. Ce matériel cryptographique permettra au terminal UA de déchiffrer ultérieurement du contenu chiffré par le serveur CSP ou par un autre serveur du même domaine csp.com ou d'un sous-domaine.
II se peut également que lors de l'étape E01 la requête pour obtenir le contenu soit une requête http non sécurisés GET http://csp.com/MMContent, et que la réponse du serveur CSP inclut un champ tel que celui décrit dans le RFC7838 (exemple: Alt-Svc: h2=:443; ma=3600), proposant l’usage d’une connexion sécurisée ou encore un champ STS décrit dans le RFC6797 imposant l’usage de HTTPS pour les échanges.
Lors d'une étape F01, connue, le serveur CSP reçoit la requête http GET et identifie un serveur primaire de livraison uCDN, avec lequel une relation d'ordre contractuel existe et auquel le serveur de contenu CSP a délégué la livraison du contenu MMContent. Ce serveur uCDN est sélectionné par le serveur CSP selon divers critères, tels que par exemple une proximité en termes de réseau avec le terminal UA, ou un profil utilisateur du terminal UA.
Dans le contexte de l'invention, ce n'est pas le serveur uCDN qui effectue la livraison du contenu en question, mais un serveur secondaire de livraison dCDN, délégué par le serveur uCDN.
Lors d'une étape F02, connue, le terminal UA est redirigé vers le serveur dCDN. Plusieurs méthodes connues, basées sur des redirections obligatoires HTTP et DNS, ou sur des redirections alternatives, ou sur une combinaison des deux, ont pour résultat final que le terminal UA dispose d’une adresse IP du serveur dCDN, et d’une adresse url vers le contenu. Le message de redirection émis lors de l'étape F02 est alors, par exemple :
http 302 redirect https://subdom.CSP.com/MMContent, que le terminal UA reçoit lors de l'étape E02.
Lors d'une étape E03, le terminal UA obtient l'adresse IP du serveur dCDN, par exemple par une requête DNS sur le nom de domaine subdomsubdom.CSP.com où subdom.csp.com est par exemple le nom du sous-domaine du domaine csp.com que le fournisseur de contenu utilise pour le contenu MMContent.
Il se peut également qu'un des serveurs impliqués dans la redirection, par exemple le serveur CSP, insère une liste de plusieurs adresses de serveur dans un message de redirection alternative émis lors de l'étape F02. Dans ce cas, lors de l'étape E03, le terminal UA obtient l'adresse IP du serveur dCDN après avoir effectué une sélection parmi les adresses de serveur comprises dans la réponse, sur des critères tels que par exemple la proximité entre le terminal UA et les serveurs de la liste, la liste étant par exemple comprise dans une réponse de type out-of-band encoding tel que décrit dans le document https://tools.ietf.org/html/draft-reschke-http-oob-encoding08.txt.
Dans tous les cas présentés ci-dessus, en fin d’étape E03 le terminal UA dispose d’une url vers le domaine ’subdom.CSP.com et de l’adresse IP d’un serveur du domaine dCDN.com, appelé serveur dCDN.
Lorsque le terminal UA a obtenu l'adresse IP du serveur dCDN, il demande, lors d'une étape E04, l'établissement d'une session chiffrée entre lui-même et le serveur dCDN. Il s’agit par exemple d'un tunnel sécurisé TLS entre le terminal UA et le serveur dCDN. Cette procédure comprend l’envoi d’un message TLS ClientHello par le terminal UA. Pour ce faire, un message tel que par exemple :
TLS ClientHello (SNI=subdom.csp.com) est émis par le terminal UA, et est reçu par le serveur dCDN lors d'une étape G01.
Le serveur dCDN détecte qu'il ne dispose pas du matériel cryptographique pour le domaine subdom.csp.com.
Lors d'une étape G02, le serveur dCDN se connecte au serveur CSP via une connexion sécurisé de type TLS où les deux entités s’authentifient mutuellement par exemple en échangeant des certificats X.509.
Lors d'une étape F03, le serveur CSP reçoit du serveur dCDN le message émis lors de l'étape G02. Il est à noter que le serveur recevant ce message peut être un serveur du domaine csp.com différent de celui ayant reçu lors de l'étape F01 la requête de contenu de la part du terminal UA. Par simplicité, s'ils sont distincts, ces deux serveurs qui sont du même domaine csp.com sont appelé serveur CSP tous les deux.
Lors d'une étape G03, le serveur dCDN émet vers le serveur CSP une demande de preuve de délégation de livraison de contenu, la demande comprenant un identifiant du serveur CSP tel que subdom.csp.com. Selon l'invention, cette demande est adressée au serveur de contenu CSP, qui agit vis-à-vis du serveur dCDN comme s'il était une autorité de certification pour son propre domaine. La demande de preuve de délégation de livraison, nommée DélégationProofQuery dans le procédé, prend par exemple la forme d'une requête CSR (Certificate Signing Request, ou requête de signature de certificat, en anglais).
Dans la technique antérieure, une requête CSR est une demande d’un certificat adressée à une autorité de certification. Selon l’invention, une DelegationProofQuery comprend en plus la description des capacités de livraison de contenu de dCDN à l’instar de celles décrites dans RFC8008 Content Delivery Network Interconnection (CDNI) Request Routing: Footprint and Capabilities Semantics. De plus une DelegatedCertificateQuery est signée avec la clé privée de dcdn.com et non avec la clé publique du certificat demandé comme dans le cas d’une requête CSR selon la technique antérieure.
Optionnellement, dCDN peut aussi inclure dans la requête DelegationProofQuery des données préalablement reçues du serveur uCDN telles qu'une signature permettant au serveur de contenu CSP d'identifier le serveur uCDN et d'en déduire l'existence d'un lien entre les serveurs uCDN et dCDN. A cette signature peut être associée une information relative à des capacités du serveur uCDN, d'ordre technique ou concernant une couverture géographique de livraison du serveur uCDN, possiblement de façon adaptée aux capacités du serveur dCDN.
Lors d'une étape F04, le serveur de contenu CSP reçoit la requête DelegationProofQuery. Puis le serveur CSP prépare le matériel cryptographique pour la délégation (clés privée et publique, certificat pour le domaine subdom.csp.com, durée de validité) ainsi que les spécifications techniques éncessaires pour la livraison du contenu dans le cadre d'une délégation au serveur dCDN, appelée données de service. Ces données de service sont adaptées aux capacités décrites par dCDN dans la requête DelegationProofQuery. Les données de service comprennent par exemple :
• le certificat pour le domaine subdom.csp.com, par exemple le certificat X.509 correspondant, y compris la clé de chiffrement publique (la clé privée est envoyée plus tard lors de l'étape F07), • des instructions permettant à dCDN d’aller acquérir le contenu auprès du serveur CSP, • des instructions pour la livraison du contenu par le serveur dCDN (format, débit, encodage des données formant le contenu, telles que décrites dans le RFC8006 Content Delivery Network Interconnection (CDNI) Metadata), • des instructions pour l’enregistrement des traces de livraison (début, fin, volume, erreurs, telles que décrites dans le RFC 7937 Content Distribution Network Interconnection (CDNI) Logging Interface).
Lors de cette étape F04, si la requête comprend une signature du serveur uCDN, le serveur de contenu CSP peut également mémoriser la requête afin de permettre une éventuelle rémunération de l'opérateur du serveur uCDN, liée à la livraison du contenu.
Lors d'une étape F05, le serveur de contenu CSP prépare et émet à destination du serveur dCDN un test sous la forme d'un fichier dit fichier challenge, que le serveur qui le reçoit doit installer à un emplacement déterminé, tel que prévu par le protocole ACME (Automatic Certificate Management Environment, draft-ietf-acmeacme-04, ou environnement de gestion automatique de certificats, en anglais) par exemple. Avantageusement selon l'invention, ce fichier de test est comprend les données de service préparées lors de l'étape F04, chiffrées à l’aide de la clé privée du certificat du domaine subdom.csp.com.
Lors d'une étape G04, le serveur dCDN reçoit le fichier challenge, et l'installe lors d'une étape G05 à l'emplacement préconisé. Il est à noter qu'à ce stade, le serveur dCDN ne peut pas déchiffrer ce fichier challenge car il ne possède pas la clé nécessaire.
Lors d'une étape F06, après expiration d'un délai déterminé, le serveur CSP vérifie que le fichier challenge est bien installé dans le serveur dCDN à l'emplacement préconisé, et qu'il est identique au fichier challenge envoyé lors de l'étape F05, tel que prévu par le protocole ACME.
Lors d'une étape F07, si le fichier challenge est accessible et conforme, le serveur CSP émet vers le serveur dCDN un message comprenant la clé de chiffrement privée liée au certificat du domaine subdom.csp.com. De préférence, ce certificat est temporaire, et sa durée de validité de l'ordre de quelques heures à une journée.
Optionnellement, si l'étape de vérification F06 échoue, ou si, dès l'étape F03, le serveur CSP détecte une incertitude sur l'authenticité du serveur dCDN, le serveur CSP insère une clé erronée dans message. Ceci présente l'avantage de maintenir active le plus longtemps possible la connexion entre les serveurs CSP et dCDN, et de donner plus de chances au serveur CSP de maintenir l'adresse IP du serveur dCDN active, afin de localiser un serveur éventuellement frauduleux ou mal configuré.
Lors d'une étape G06, le serveur dCDN reçoit le message comprenant la clé privée du certificat pour le domaine subdom.csp.com. Le serveur déchiffre le fichier challenge comprenant les données de service, à l'aide de la clé privée.
Lors d'une étape G07, le serveur dCDN répond à la demande d'établissement d'une session chiffrée émise par terminal client UA lors de l'étape E04, avec le certificat du domaine subdom.csp.com. Pour ce faire, un ou plusieurs messages tels que par exemple :
TLS ServerHello (cert (subdom.scp.com)) est émis par le serveur dCDN, et est reçu par le terminal UA lors d'une étape E05. La connexion TLS demandée par le terminal UA peut alors être établie, car le certificat émis par le serveur dCDN correspond à celui du domaine subdom.csp.com, sauf si lors de l'étape F07 le serveur CSP a émis vers le serveur dCDN une clé erronée.
Lors d'une étape G08 qui peut être exécutée avant, après ou en parallèle de l'étape G07, le serveur dCDN prend en compte les données de service afin d'obtenir auprès du serveur CSP le contenu à livrer.
Lors d'une étape G09, le serveur dCDN transmet le contenu au terminal UA. Pour le terminal client UA, tout s'est passé de façon transparente, comme si le serveur dCDN était délégué officiellement par le fournisseur du contenu pour le livrer au terminal.
Lors d'une étape G10 optionnelle, le serveur dCDN envoie au serveur CSP l’enregistrement des traces de livraison, à des fins de comptabilité.
La figure 3 présente un exemple de structure de dispositif de demande de preuve de délégation 300, permettant la mise en oeuvre d’un procédé de demande de preuve de délégation selon l’un quelconque des modes de réalisation décrits ci-dessus en relation avec la figure 2.
Le dispositif de demande de preuve de délégation 300 comprend une mémoire vive 303 (par exemple une mémoire RAM), une unité de traitement 302, équipée par exemple d'un processeur, et pilotée par un programme d'ordinateur stocké dans une mémoire morte 301 (par exemple une mémoire ROM ou un disque dur). A l'initialisation, les instructions de code du programme d'ordinateur sont par exemple chargées dans la mémoire vive 303 avant d'être exécutées par le processeur de l'unité de traitement 302.
La figure 3 illustre seulement un mode particulier de réalisation, parmi plusieurs modes particuliers de réalisation possibles, du procédé de demande de preuve de délégation détaillé ci-dessus, en relation avec la figure 2. En effet, la technique de l’invention se réalise indifféremment sur une machine de calcul reprogrammable (un ordinateur PC, un processeur DSP ou un microcontrôleur) exécutant un programme comprenant une séquence d’instructions, ou sur une machine de calcul dédiée (par exemple un ensemble de portes logiques comme un FPGA ou un ASIC, ou tout autre module matériel).
Dans le cas où l’invention est implantée sur une machine de calcul reprogrammable, le programme correspondant (c'est-à-dire la séquence d’instructions) pourra être stocké dans un médium de stockage amovible ou non, ce médium de stockage étant lisible partiellement ou totalement par un ordinateur ou un processeur.
Le dispositif de demande de preuve de délégation comprend également un module de communication (COM) adapté pour émettre une demande de preuve de délégation de livraison, une réponse d'établissement d'une connexion chiffrée, et pour recevoir un demande d'établissement d'une connexion chiffrée, un message comprenant une clé de chiffrement, et une instruction relative à une capacité à livrer du contenu.
Selon un mode de réalisation, un tel dispositif de demande de preuve de délégation est compris dans un serveur de diffusion de contenu, par exemple un serveur de cache apte à diffuser du contenu.
La figure 4 présente un exemple de structure de dispositif de délégation 400, permettant la mise en œuvre d’un procédé de délégation selon l’un quelconque des modes de réalisation décrit ci-dessus en relation avec la figure 2.
Le dispositif de délégation 400 comprend une mémoire vive 403 (par exemple une mémoire RAM), une unité de traitement 402, équipée par exemple d'un processeur, et pilotée par un programme d'ordinateur stocké dans une mémoire morte 401 (par exemple une mémoire ROM ou un disque dur). A l'initialisation, les instructions de code du programme d'ordinateur sont par exemple chargées dans la mémoire vive 403 avant d'être exécutées par le processeur de l'unité de traitement 402.
La figure 4 illustre seulement une manière particulière, parmi plusieurs possibles, de mise en œuvre le procédé de délégation détaillé ci-dessus, en relation avec la figure 2. En effet, la technique de l’invention se réalise indifféremment sur une machine de calcul reprogrammable (un ordinateur PC, un processeur DSP ou un microcontrôleur) exécutant un programme comprenant une séquence d’instructions, ou sur une machine de calcul dédiée (par exemple un ensemble de portes logiques comme un FPGA ou un ASIC, ou tout autre module matériel).
Dans le cas où l’invention est implantée sur une machine de calcul reprogrammable, le programme correspondant (c'est-à-dire la séquence d’instructions) pourra être stocké dans un médium de stockage amovible ou non, ce médium de stockage étant lisible partiellement ou totalement par un ordinateur ou un processeur.
Le dispositif de délégation comprend également un module de communication (COMj adapté pour recevoir une demande de preuve de délégation, et pour émettre une réponse comprenant une clé de chiffrement, et une instruction relative à une capacité à livrer le contenu.
Dans un mode de réalisation, un tel dispositif de délégation est compris dans un serveur, par exemple un serveur d’un fournisseur de contenu apte à référencer ledit contenu.

Claims (15)

  1. REVENDICATIONS
    1. Procédé de demande de preuve de délégation pour la livraison d'un contenu à un terminal client (UA) au travers d'une connexion chiffrée, le contenu étant référencé sur un serveur (CSP) dit serveur de contenu, vers lequel le terminal client a émis une requête (E01) pour obtenir le contenu, le serveur de contenu ayant délégué la livraison dudit contenu à un serveur dit serveur primaire de livraison (uCDN), le procédé étant mis en œuvre par un serveur de livraison dit serveur secondaire de livraison (dCDN), auquel le serveur primaire de livraison a délégué la livraison dudit contenu, et comprenant les étapes suivantes :
    • réception (G01) d'une demande d'établissement de la connexion chiffrée, en provenance du terminal client, comprenant un identifiant du serveur de contenu, • émission (G03) d'une demande de preuve de délégation de livraison, à destination du serveur de contenu, • réception (G06) d'un message en provenance du serveur de contenu, comprenant une clé de chiffrement, • émission (G07) d'une réponse d'établissement de la connexion chiffrée, à destination du terminal client, • établissement (G09) de la connexion chiffrée avec le terminal client à l'aide de la clé de chiffrement.
  2. 2. Procédé selon la revendication précédente, comprenant en outre les étapes suivantes :
    • obtention (G08) du contenu auprès du serveur de contenu, • livraison du contenu au terminal client au travers de la connexion chiffrée.
  3. 3. Procédé selon l'une des revendications précédentes, comprenant les étapes suivantes, préalablement à l'étape de réception (G06) du message comprenant la clé de chiffrement :
    • réception (G04) d'au moins une instruction relative à une capacité à livrer le contenu, en provenance du serveur de contenu, • exécution (G05) de l'instruction.
  4. 4. Procédé selon l'une des revendications précédentes, où la demande de certification comprend une information relative aux capacités de livraison du serveur secondaire de livraison.
  5. 5. Procédé de délégation pour la livraison d'un contenu à un terminal client (UA) au travers d'une connexion chiffrée, le contenu étant référencé sur un serveur (CSP) dit serveur de contenu vers lequel le terminal client a émis une requête pour obtenir le contenu, le serveur de contenu ayant délégué la livraison dudit contenu à un serveur dit serveur primaire de livraison (uCDN), le serveur primaire de livraison ayant délégué la livraison dudit contenu à un serveur dit serveur secondaire de livraison (dCDN), le procédé étant mis en œuvre par le serveur de contenu, et comprenant les étapes suivantes :
    • réception (F04) d'une demande de preuve de délégation, en provenance du serveur secondaire de livraison, • analyse (F05, F06) de la demande, • en fonction du résultat de l'analyse, émission (F07) d'une réponse comprenant une clé de chiffrement associée au serveur de contenu.
  6. 6. Procédé selon la revendication 5, où l'étape d'analyse comprend les étapes suivantes :
    • émission (F05) d'au moins une instruction relative à une capacité à livrer le contenu, à destination du serveur secondaire de livraison, • vérification (F06) de l'exécution de l'instruction.
  7. 7. Procédé selon la revendication 6, où la réponse n'est pas émise si l'exécution de l'instruction n'est pas vérifiée après expiration d'une durée déterminée par le serveur de contenu.
  8. 8. Procédé selon la revendication 6, où la réponse est émise avec une fausse clé si l'exécution de l'instruction n'est pas vérifiée après expiration d'une durée déterminée par le serveur de contenu, ou si le serveur secondaire de livraison n'est pas authentifié par une autorité de certification.
  9. 9. Procédé selon l'une des revendications précédentes, où la demande de preuve de délégation est un message de type Certificate Signing Request.
  10. 10. Dispositif de demande de preuve de délégation pour la livraison d'un contenu à un terminal client (UA) au travers d'une connexion chiffrée, le contenu étant référencé sur un serveur (CSP) dit serveur de contenu, vers lequel le terminal client a émis une requête (E01) pour obtenir le contenu, le serveur de contenu ayant délégué la livraison dudit contenu à un serveur dit serveur primaire de livraison (uCDN), le serveur primaire de livraison ayant délégué la livraison dudit contenu à un serveur de livraison dit serveur secondaire de livraison (dCDN), le dispositif comprenant une machine de calcul reprogrammable (302) ou une machine de calcul dédiée, apte à et configurée pour :
    • recevoir une demande d'établissement de la connexion chiffrée, en provenance du terminal client, comprenant un identifiant du serveur de contenu, • émettre une demande de preuve de délégation de livraison, à destination du serveur de contenu, • recevoir un message en provenance du serveur de contenu, comprenant une clé de chiffrement, • émettre une réponse d'établissement de la connexion chiffrée, à destination du terminal client, • établir la connexion chiffrée avec le terminal client à l'aide de la clé de chiffrement.
  11. 11. Dispositif de délégation pour la livraison d'un contenu à un terminal client (UA) au travers d'une connexion chiffrée, le contenu étant référencé sur un serveur (CSP) dit serveur de contenu vers lequel le terminal client a émis une requête pour obtenir le contenu, le serveur de contenu ayant délégué la livraison dudit contenu à un serveur dit serveur primaire de livraison (uCDN), le serveur primaire de livraison ayant délégué la livraison dudit contenu à un serveur dit serveur secondaire de livraison (dCDN), le dispositif comprenant une machine de calcul reprogrammable (402) ou une machine de calcul dédiée, apte à et configurée pour :
    • recevoir une demande de preuve de délégation, en provenance du serveur secondaire de livraison, • analyser la demande, • en fonction du résultat de l'analyse, émettre une réponse comprenant une clé de chiffrement associée au serveur de contenu.
  12. 12. Système de délégation comprenant un serveur de contenu (CSP), un serveur secondaire de livraison(dCDN), et un terminal client (UA), le serveur de contenu comprenant un dispositif de délégation conforme à la revendication 11, le serveur secondaire de livraison comprenant un dispositif de demande de preuve de délégation conforme à la revendication 10.
  13. 13. Produit programme d'ordinateur, comprenant des instructions de code de programme pour la mise en oeuvre du procédé selon l’une quelconque des revendications 1 à 9, lorsque ledit programme est exécuté sur un ordinateur.
  14. 14. Support d’enregistrement lisible par un serveur de diffusion de contenu (dCDN) sur lequel est enregistré le programme selon la revendication 13.
  15. 15. Support d’enregistrement lisible par un serveur de référencement contenu (CSP) sur lequel est enregistré le programme selon la revendication 13.
    Page 1/2
FR1750324A 2017-01-16 2017-01-16 Procedes et dispositifs de delegation de diffusion de contenus chiffres Pending FR3062012A1 (fr)

Priority Applications (4)

Application Number Priority Date Filing Date Title
FR1750324A FR3062012A1 (fr) 2017-01-16 2017-01-16 Procedes et dispositifs de delegation de diffusion de contenus chiffres
US16/478,350 US11258770B2 (en) 2017-01-16 2018-01-16 Methods and devices for delegation of distribution of encrypted content
EP18703059.8A EP3568966B1 (fr) 2017-01-16 2018-01-16 Procédés et dispositifs de délégation de diffusion de contenus chiffrés
PCT/FR2018/050106 WO2018130797A1 (fr) 2017-01-16 2018-01-16 Procédés et dispositifs de délégation de diffusion de contenus chiffrés

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1750324A FR3062012A1 (fr) 2017-01-16 2017-01-16 Procedes et dispositifs de delegation de diffusion de contenus chiffres
FR1750324 2017-01-16

Publications (1)

Publication Number Publication Date
FR3062012A1 true FR3062012A1 (fr) 2018-07-20

Family

ID=59070747

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1750324A Pending FR3062012A1 (fr) 2017-01-16 2017-01-16 Procedes et dispositifs de delegation de diffusion de contenus chiffres

Country Status (4)

Country Link
US (1) US11258770B2 (fr)
EP (1) EP3568966B1 (fr)
FR (1) FR3062012A1 (fr)
WO (1) WO2018130797A1 (fr)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3970318A1 (fr) * 2019-05-16 2022-03-23 Telefonaktiebolaget Lm Ericsson (Publ) Gestion de services de transmission libre dans un réseau de communication
EP3970446A1 (fr) * 2019-05-16 2022-03-23 Telefonaktiebolaget Lm Ericsson (Publ) Gestion hors offre du fournisseur d'accès à l'internet dans un réseau de communication
FR3110801A1 (fr) * 2020-05-25 2021-11-26 Orange Procédé de délégation de la livraison de contenus à un serveur cache
US11722561B2 (en) * 2020-12-22 2023-08-08 Telefonaktiebolaget Lm Ericsson (Publ) DTLS/SCTP enhancements for RAN signaling purposes

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150106624A1 (en) * 2011-12-16 2015-04-16 Akamai Technologies, Inc. Providing forward secrecy in a terminating TLS connection proxy

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8340283B2 (en) * 2004-06-30 2012-12-25 International Business Machines Corporation Method and system for a PKI-based delegation process
US10713379B2 (en) * 2014-04-21 2020-07-14 David Lane Smith Distributed storage system for long term data storage

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150106624A1 (en) * 2011-12-16 2015-04-16 Akamai Technologies, Inc. Providing forward secrecy in a terminating TLS connection proxy

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
LIANG JINJIN ET AL: "When HTTPS Meets CDN: A Case of Authentication in Delegated Service", 2014 IEEE SYMPOSIUM ON SECURITY AND PRIVACY, IEEE, 18 May 2014 (2014-05-18), pages 67 - 82, XP032686141, ISSN: 1081-6011, [retrieved on 20141113], DOI: 10.1109/SP.2014.12 *
SOLLINS K R: "Cascaded authentication", SECURITY AND PRIVACY, 1988. PROCEEDINGS., 1988 IEEE SYMPOSIUM ON OAKLAND, CA, USA 18-21 APRIL 1, WASHINGTON, DC, USA,IEEE COMPUT. SOC. PR, US, 18 April 1988 (1988-04-18), pages 156 - 163, XP010012310, ISBN: 978-0-8186-0850-6, DOI: 10.1109/SECPRI.1988.8108 *

Also Published As

Publication number Publication date
EP3568966A1 (fr) 2019-11-20
EP3568966B1 (fr) 2022-11-23
WO2018130797A1 (fr) 2018-07-19
US20190372943A1 (en) 2019-12-05
US11258770B2 (en) 2022-02-22

Similar Documents

Publication Publication Date Title
EP3568966B1 (fr) Procédés et dispositifs de délégation de diffusion de contenus chiffrés
EP3087720B1 (fr) Technique de contrôle du routage d'une requête relative a un service
EP1909462A2 (fr) Procédé de mise à disposition cloisonnée d'un service électronique
WO2018130796A1 (fr) Procédés et dispositifs de vérification de la validité d'une délégation de diffusion de contenus chiffrés
WO2018115647A1 (fr) Validation de livraison de contenu et de verification d'une delegation de livraison d'un contenu
FR2872363A1 (fr) Procede et systeme de certification de l'identite d'un utilisateur
EP2630765B1 (fr) Procede d'optimisation du transfert de flux de donnees securises via un reseau autonomique
WO2020128238A1 (fr) Procédé d'acquisition d'une chaîne de délégation relative à la résolution d'un identifiant de nom de domaine dans un réseau de communication
EP3149902B1 (fr) Technique d'obtention d'une politique de routage de requêtes émises par un module logiciel s'exécutant sur un dispositif client
WO2020128239A1 (fr) Procédé de détermination d'une chaîne de délégation associée à une résolution d'un nom de domaine dans un réseau de communication
FR3015839A1 (fr) Procede de ralentissement d'une communication dans un reseau
EP2446608B1 (fr) Technique de contrôle d'accès par une entité cliente à un service
WO2021240098A1 (fr) Procede de delegation de la livraison de contenus a un serveur cache
WO2021260327A1 (fr) Procede de controle d'acces a un contenu mis en œuvre par un serveur cache
EP2525525B1 (fr) Procédé, programme d'ordinateur et dispositif de cooptation permettant à un abonné d'un service de partager ce service avec un autre utilisateur
WO2024047128A1 (fr) Procédé, dispositif et système de contrôle de la validité d'un message
FR3137238A1 (fr) Procédé de suspension d’un jeton de certification permettant d’authentifier l’établissement d’une connexion entre deux équipements de communication, dispositifs et programmes d’ordinateur correspondants
FR3108816A1 (fr) Procédé de délégation d’une fonction de résolution d’identifiants de nommage
WO2018234662A1 (fr) Procédé de contrôle de l'obtention par un terminal d'un fichier de configuration
FR3051090A1 (fr) Moyens de mesures de performance d’une connexion internet d’un terminal
FR3044192A1 (fr) Procede de distribution de droits sur un service et plateforme de service
FR3029043A1 (fr) Procede de notification de messages

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20180720

RX Complete rejection

Effective date: 20200115