Brevet FR3062012A1 — publié le 20180720

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 ILS (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. ILS 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 3062012 2 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 5 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 10 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 15 contenu ayant délégué la livraison dudit contenu à un serveur dit serveur primaire de livraison, le procédé étant mis en oeuvre 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 20 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, 25 - é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. 30 Selon la technique antérieure, un terminal demandant un contenu à un serveur 3062012 3 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 5 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 10 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, 15 - 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. 20 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, 25 - 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 30 contenu. 3062012 4 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 5 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. 10 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 15 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, 20 - 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 25 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. 30 Selon un aspect de l'invention, l'étape d'analyse comprend les étapes 3062012 5 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. 5 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. 10 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 15 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 20 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é 25 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 à 30 partir de son adresse IP, et d'engager une éventuelle action visant à neutraliser ou 3062012 6 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. 5 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 ILS. 10 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 15 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 20 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 25 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, 30 - établir la connexion chiffrée avec le terminal client à l'aide de la clé de chiffrement. 3062012 7 Ce dispositif de demande de preuve de délégation, apte à mettre en oeuvre 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 oeuvre dans un serveur de diffusion de contenu. 5 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 10 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 15 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 oeuvre dans tous ses modes de 20 réalisation le procédé de délégation qui vient d'être décrit, est destiné à être mis en oeuvre 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 25 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. 30 L'invention vise enfin : 3062012 8 - 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 5 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 10 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. 15 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 disc) ou un disque dur. 20 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 25 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 30 D'autres avantages et caractéristiques de l'invention apparaitront plus 3062012 9 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 5 dans la technique décrite, - la figure 2 présente un exemple d'enchainement 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 10 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 15 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 ILS 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 OU 10. 20 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 25 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 30 terminal client UA pouvant embarquer un ou plusieurs agents clients ("User Agent" en 3062012 10 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 5 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. ; 10 - 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. 15 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. 20 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 25 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 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. 30 Un utilisateur d'un terminal UA souhaite consommer un contenu multimédia 3062012 11 MMContent, référencé par un fournisseur de contenu, dont il connait 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 5 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 10 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 15 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 20 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 25 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. Il 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 30 (exemple: Alt-Svc: h2=":443"; ma=3600), proposant l'usage d'une connexion sécurisée 3062012 12 ou encore un champ SIS 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 5 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 10 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 15 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. 20 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 25 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, 30 la liste étant par exemple comprise dans une réponse de type out-of-band encoding tel 3062012 13 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 5 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é ILS entre le terminal UA et le serveur dCDN. Cette procédure comprend l'envoi d'un message ILS ClientHello par le terminal 10 UA. Pour ce faire, un message tel que par exemple : "ILS 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 15 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 ILS 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 20 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. 25 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 30 de délégation de livraison, nommée DelegationProofQuery dans le procédé, prend par 3062012 14 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 5 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 10 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 15 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 20 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 25 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 30 du serveur CSP, 3062012 15 - 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 lnterconnection (CDNI) Metadata"), 5 - 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 lnterconnection (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 10 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 15 protocole ACME (Automatic Certificate Management Environment, "draft-ietf-acme- acme-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". 20 Lors d'une étape G04, le serveur dCDN reçoit le fichier challenge, et l'installe lors d'une étape GO5 à l'emplacement préconisé. Il est à noter qu'a 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 25 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 30 privée liée au certificat du domaine "subdom.csp.com". De préférence, ce certificat est 3062012 16 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 5 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 10 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 : 15 "ILS 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 ILS 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. 20 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 25 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é. 30 La figure 3 présente un exemple de structure de dispositif de demande de 3062012 17 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 5 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. 10 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 15 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) 20 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 25 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 30 serveur de cache apte à diffuser du contenu. 3062012 18 La figure 4 présente un exemple de structure de dispositif de délégation 400, permettant la mise en oeuvre 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. 5 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 10 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 oeuvre 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 15 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) 20 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 (COM') 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 25 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. 30 REVENDICATIONS1. 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 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. 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. 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 3062012 20 contenu, en provenance du serveur de contenu, - exécution (G05) de l'instruction. 4. Procédé selon l'une des revendications précédentes, où la demande de certification 5 comprend une information relative aux capacités de livraison du serveur secondaire de livraison. 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 10 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 oeuvre par le serveur de contenu, et comprenant les étapes 15 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 20 clé de chiffrement associée au serveur de contenu. 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 25 contenu, à destination du serveur secondaire de livraison, - vérification (F06) de l'exécution de l'instruction. 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 30 de contenu. 3062012 21 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é 5 par une autorité de certification. 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 15 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 20 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, 25 - é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. Dispositif de délégation pour la livraison d'un contenu à un terminal client (UA) au 30 travers d'une connexion chiffrée, le contenu étant référencé sur un serveur (CSP) dit 3062012 22 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 5 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, 10 - en fonction du résultat de l'analyse, émettre une réponse comprenant une clé de chiffrement associée au serveur de contenu. 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 15 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. Produit programme d'ordinateur, comprenant des instructions de code de 20 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. Support d'enregistrement lisible par un serveur de diffusion de contenu (dCDN) sur lequel est enregistré le programme selon la revendication 13. 25 15. Support d'enregistrement lisible par un serveur de référencement contenu (CSP) sur lequel est enregistré le programme selon la revendication 13.