EP3568989A1 - Procédés et dispositifs de vérification de la validité d'une délégation de diffusion de contenus chiffrés - Google Patents

Procédés et dispositifs de vérification de la validité d'une délégation de diffusion de contenus chiffrés

Info

Publication number
EP3568989A1
EP3568989A1 EP18704274.2A EP18704274A EP3568989A1 EP 3568989 A1 EP3568989 A1 EP 3568989A1 EP 18704274 A EP18704274 A EP 18704274A EP 3568989 A1 EP3568989 A1 EP 3568989A1
Authority
EP
European Patent Office
Prior art keywords
server
delegation
terminal
certificate
content
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
EP18704274.2A
Other languages
German (de)
English (en)
Inventor
Emile Stephan
Frédéric 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
Publication of EP3568989A1 publication Critical patent/EP3568989A1/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/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/258—Client or end-user data management, e.g. managing client capabilities, user preferences or demographics, processing of multiple end-users preferences to derive collaborative data
    • H04N21/25808—Management of client data
    • H04N21/25816—Management of client data involving client authentication
    • 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
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/21—Server components or server architectures
    • H04N21/222—Secondary servers, e.g. proxy server, cable television Head-end
    • 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/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/237—Communication with additional data server
    • 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/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/254—Management at additional data server, e.g. shopping server, rights management server
    • H04N21/2541—Rights Management
    • 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/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/258—Client or end-user data management, e.g. managing client capabilities, user preferences or demographics, processing of multiple end-users preferences to derive collaborative data
    • H04N21/25866—Management of end-user data
    • H04N21/25875—Management of end-user data involving end-user authentication

Definitions

  • the invention is in the field of content distribution networks, and more particularly for encrypted content.
  • TLS Transport Layer Security
  • TLS makes it possible to authenticate the server or the client, to encrypt the contents of the exchanges between them and to check their integrity.
  • a request is sent to a server of a content provider.
  • this content provider delegates the delivery of the content to another server, chosen according to several criteria, such as, for example, the location of the customer's terminal and the terms of the contract between the content provider and the service provider. other server, when this contract exists.
  • the client terminal has no way of checking the validity of this delegation. This is all the more problematic since the CDNs (Content Delivery Network), to which the delivery of the content is delegated, are more and more numerous, and can delegate to one another the delegation that they received from a content provider, without the latter necessarily knowing it.
  • CDNs Content Delivery Network
  • the invention improves the situation by using a method of verifying a delegation certificate, the delegation being from a first server to a second server, for a delivery of referenced content on the first server, and intended for a client terminal, the method comprising the following steps implemented by the terminal:
  • Receiving a redirection message comprising at least one identifier of a third party server
  • the verification method is particular in that it further comprises the following steps:
  • the verification method according to the invention enables the terminal to check whether the Delegation of delivery of the content by encrypted connection is good.
  • the terminal When a terminal requires content from a content server, and this server has delegated the delivery of this content to a third party server, the terminal receives from the first server a redirection message comprising an identifier of this third party server, to which it has delegated the delivery of the content. With this identifier, the terminal obtains an address, which can be that corresponding to the identifier, but which can also be that of another server, to which the third party server has itself delegated its role. This is called multiple delegation. This second delegation to this other server, in cascade of the first, can be done for example using a simple DNS redirection, invisible from the first server.
  • the terminal can ensure that all the servers involved in the delegation chain are authenticated by a CA, but nothing allows it to verify the validity of the second delegation, let alone the validity of any subsequent delegation, in case multiple delegation to more than two levels.
  • OCSP Online Certificate Status Protocol
  • the terminal receives from the second server a delegation certificate, allowing it to decide whether to access the content or not, depending on its verification of the certificate. This check is done using a public key specific to the first server, the terminal can verify that the delegation certificate received from the second server has been established with the agreement of the first server.
  • the terminal can verify that the delegation certificate received from the second server validly established at a given time with the agreement of the first server, is still valid at the moment when the terminal requires the content. Moreover, in this case, this process gives an opportunity to the second server to renew its certificate of delegation to the first server if it has become too old.
  • the step of obtaining an address of the second server comprises a step of selecting the address among the identifiers of third-party servers, and / or a step of interrogating a server of address resolution with an identifier.
  • the terminal can select one according to its own criteria. Similarly, if the redirection message from the first server includes a domain name, the terminal can obtain an address from this name by performing a DNS query.
  • the method further comprises a step of sending a second request message of the content, to the second server, through the second encrypted connection, if the verified delegation certificate is valid. .
  • the client terminal consumes the requested content through a connection with the second server, to which the first server has legitimately delegated the delivery.
  • the certification message further comprises a redirection instruction and wherein the method further comprises a step of redirecting the terminal to a third server.
  • the first server can invite the terminal to connect to a server other than the second server. server rather than staying connected to the second server.
  • This redirection server may be the first server, or a site or a server determined by the first server.
  • the site may for example be an informational page warning that the second server is not a suitable server to deliver the requested content.
  • the server can be a alternative delivery server, preferable to the second server.
  • the invention also relates to a method for producing a delegation certificate, the delegation being from a first server to a second server, for a delivery of referenced content on the first server, and intended for a client terminal, the method comprising the following steps implemented by the first server: ⁇ receiving a content request message from the terminal, through a first encrypted connection between the terminal and the first server, by means of which the terminal has previously obtained an encryption key associated with the first server,
  • the production process is particular in that it further comprises the following steps:
  • the first server can decide, if it is appropriate according to criteria specific to the first server, to provide a second server which is not necessarily the third server to which the first server may already have delegated the delivery of the content, information regarding the delegation of the first to the second server. This information can not be changed by the second server, but can be verified by the terminal to which the second server transmits it.
  • the request message for a delegation certificate further comprises an address of the client terminal.
  • the first server can thus take into account, during the analysis step, the address of the terminal requesting the content. This is useful because with the address it is possible to determine the geographical location, and, knowing the address of the second server, the first server can determine if the distance between the terminal and the second server is conducive to satisfactory delivery of the content.
  • the request message for a delegation certificate further comprises a signature of the third party server.
  • the first server can thus take into account, during the analysis step, the signature of the third party server. This is useful because this third party server normally has a valid delegation from the first server, or has in any case already disposed of.
  • the second server can therefore deduce that the second server has obtained a delegation of the third server, which reinforces the legitimacy of the second server from the first server.
  • the delegation certificate response message further comprises a redirection instruction for the client terminal.
  • the first server may invite the terminal to connect to a site determined by the first server, rather than remain connected to the second server.
  • This site may for example be a warning page informing that the second server is not a suitable server to deliver the requested content, or be an alternative delivery server, preferable to the second server for example because of higher performance.
  • the invention also concerns a method for requesting a delegation certificate, the delegation being from a first server to a second server, for a delivery of a referenced content on the first server, and intended for a client terminal (UA ), the method comprising the following steps implemented by the second server:
  • the requesting method is particular in that it further comprises the following steps:
  • the terminal Issuing a certification message to the terminal, including the delegation certificate, through the second encrypted connection, the terminal having previously obtained an encryption key associated with the first server, by means of a first encrypted connection between the terminal and the first server.
  • the second server receives a request to establish a connection of a terminal wishing to consume content referenced on the first server, the second server is able to prove that it has obtained a valid delegation from the server. first server.
  • the invention also concerns a device for verifying a delegation certificate, the delegation being from a first server to a second server, for a delivery of a referenced content on the first server, and intended for a client terminal, the device comprising a reprogrammable calculating machine or a machine for dedicated calculation, suitable for and configured for:
  • This verification device able to implement in all its embodiments the verification method just described, is intended to be implemented in a client terminal or in an application included in the terminal such that a browser.
  • the invention also relates to a device for producing a delegation certificate, the delegation being from a first server to a second server, for a delivery of a referenced content on the first server, and intended for a client terminal, the device comprising a reprogrammable calculating machine or a dedicated calculating machine, adapted to and configured for:
  • the invention also relates to a device for requesting a delegation certificate, the delegation being from a first server to a second server, for a delivery of a referenced content on the first server, and intended for a client terminal, the device comprising a reprogrammable calculating machine or a dedicated calculating machine, adapted to and configured for:
  • the invention also relates to a system for verifying a delegation certificate, comprising a verification device, a production device and a device for requesting a certificate of delegation.
  • the invention finally aims at:
  • a computer program comprising instructions for implementing the steps of the verification method just described, when this program is executed by a processor, as well as an information medium readable by a client terminal, and comprising instructions of this computer program, ⁇ a computer program comprising instructions for implementing the steps of the production method just described, when this program is executed by a processor, as well as an information carrier readable by a content referencing server, and including instructions of this computer program,
  • a computer program comprising instructions for implementing the steps of the application method which has just been described, when this program is executed by a processor, as well as an information medium readable by a broadcast server; content, and including instructions from this computer program.
  • These programs can use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any other form desirable shape.
  • the information carriers may be any entity or device capable of storing the program.
  • a medium may comprise a storage medium, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording means, for example a floppy disk or a hard disk.
  • such an information medium may be a transmissible medium such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio or by other means.
  • a program according to the invention can in particular be downloaded to an Internet type network.
  • an information carrier according to the invention may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the processes in question.
  • FIG. 1 illustrates a network configuration locating the entities involved in the technique described
  • FIG. 2 shows an example of concatenation and implementation of the steps of the process for requesting a delegation certificate, the procedure for verifying a delegation certificate and the method for producing a delegation certificate, according to one aspect of the invention
  • FIG. 3 shows an exemplary structure of a verification device of a delegation certificate, according to one aspect of the invention
  • FIG. 4 shows an exemplary structure of a device for producing a delegation certificate, according to one aspect of the invention
  • FIG. 5 shows an exemplary structure of a device for requesting a delegation certificate, according to one aspect of the invention. 5. Detailed description of at least one embodiment of the invention
  • a CSP server of a content provider referencing different contents (for example multimedia content, of the type comprising sounds, images or videos, or executable files) intended to be distributed to end-user client terminals;
  • contents for example multimedia content, of the type comprising sounds, images or videos, or executable files
  • a client terminal UA for example a computer, a smartphone of a user, seeking to obtain content from the content provider, such a client terminal UA that can load one or more client agents ("User Agent") of the http type (for "HyperText Transfer Protocol” in English) or HTTPS (for "HyperText Transfer Protocol Secure” in English) or Internet browser type;
  • an uCDN content delivery server to which the content provider's CSP server has delegated the delivery of the content in question and which is known to the content provider's CSP server using a domain name;
  • a dCDN content delivery secondary to which the uCDN content delivery primary has potentially delegated delivery of the content sought by the user of the client terminal UA in a dual delegation context.
  • a DNS domain name resolution server for associating a domain name with a network address
  • a CA server of a certification authority for issuing certificates, for example according to the HTTPS protocol (for "HyperText Transfer Protocol Secure "in English), to the servers in question.
  • HTTPS protocol for "HyperText Transfer Protocol Secure "in English
  • a telecommunications network 100 for the transmission of data, for example based on an internet protocol.
  • an LDNS local domain name resolution server uses a central DNS server.
  • each server can use a different CA server.
  • the delivery servers uCDN and dCDN can be grouped into one and the same hardware entity.
  • more delivery servers are present, for example in a context of cascading delegations.
  • FIG. 2 shows an example of concatenation and implementation of the steps of the process for requesting a delegation certificate, the process for verifying a delegation certificate and the method for producing a delegation certificate, according to FIG. an aspect of the invention.
  • a user of a UA terminal wishes to consume MMContent multimedia content, referenced by a content provider, of which he knows or has obtained the identity in any way.
  • the terminal UA retrieves the domain name of a CSP server associated with the content provider, on which the MMContent content is referenced.
  • This address is for example in the form of url (Uniform Resource Locator, or 'uniform resource locator', in English), such as 'csp.com'.
  • the terminal UA issues a request to obtain the content MMContent.
  • the term "terminal” is used in this document, but it can represent such an application or such a browser (called “browser” in English), installed or installed on the terminal.
  • This request to obtain the content is for example an http request using the https protocol, such as:
  • This request follows a procedure for establishing a secure tunnel
  • TLS between the UA terminal and the CSP server.
  • This procedure involves sending a TLS ClientHello message by the UA.
  • the server CSP sends in response to the terminal UA a ServerHello message comprising cryptographic material such as a public key to which is associated a private key held by the administrator of the CSP domain, or a SessionTicket session ticket (as described in RFC5077).
  • the public key is usually attached to a certificate of the CSP server, which the CSP server has obtained after any certification authority.
  • This hardware will allow the UA terminal to later decrypt content encrypted by the CSP server or another server in the same domain 'csp.com'
  • the CSP server receives the HTTP request GET and identifies a third party server with which a contractual relationship exists. This server is selected by the server CSP according to various criteria, such as for example a proximity in terms of network with the terminal UA, or a user profile of the terminal UA.
  • the UA is redirected step by step to the server in charge of delivering the content.
  • the third party server is the one that delivers the content to the UA terminal.
  • the third party server is then the dCDN server.
  • the third server is the uCDN server and this other server is the dCDN server.
  • the server CSP also sends to the terminal UA a redirection message in response to the request "http GET https://csp.com/MMContent ", including the address of the DCN server," dcdn.com "This redirect message is for example:
  • the redirection message sent during the step F02 is then, for example:
  • the terminal UA obtains the IP address of the dCDN server by a DNS query on the domain name "dcdn.com".
  • the terminal UA obtains the IP address of the DCN server after having made a selection among the server addresses included in the response, on criteria such as, for example, the proximity between the terminal UA. and the servers in the list, the list being included in an out-of-band encoding response as described in the document "https://tools.ietf.org/html/draft-reschke-http-oob-encoding -08.txt ".
  • the terminal UA has an url to the domain 'dCDN.com' and the IP address of a server of 'dCDN.com', the server dCDN.
  • the terminal UA When the terminal UA has obtained the address of the DCN server, it requests, during a step E04, the establishment of an encrypted session between itself and the DCN server. This is for example a secure TLS tunnel between the UA terminal and the DCN server.
  • This procedure includes sending a TLS ClientHello message by the UA terminal. To do this, this message is sent by the terminal UA, received by the CDN server during a step G01, comprising, in a preferred embodiment of the invention, a request to the DCN server to prove that it has obtained a valid delegation from a server of the domain 'csp.com'.
  • This message may be, for example, a message according to a modification of the TLS protocol, comprising a DCQ delegation certificate request (for Delegation Challenge Query, or proof of delegation request, in English), such as:
  • the content of the message is signed using a key previously obtained by the terminal UA, such as a SessionTicket key, so that the dCDN server can not modify the content of the DCQ request.
  • a key previously obtained by the terminal UA such as a SessionTicket key
  • the DCN server In order to obtain the proof required by the UA terminal, called the delegation certificate, the DCN server must request it, or have previously requested it, from the 'csp.com' domain.
  • the delegation certificate request sent by the CDN server during a step G02 is triggered by the step E04.
  • This mode is useful when, for example, no relationship exists beforehand between the CSP server and the DCN server, or when the delegation certificate in possession of the DCN server is old and must be renewed.
  • the terminal UA can insert information previously received, such as for example:
  • a signature of the redirection URL inserted by the uCDN server the purpose of which is to prove to the DCN server that the request received from the terminal UA actually originates from a redirection initiated by the uCDN server; • a SessionTicket received from the CSP server, whose purpose is to enable the
  • asynchronous mode the DCN server periodically requests this delegation certificate, independently of the step E04, in order to be ready to provide at any time, on request of a terminal such as as the UA terminal, a recent proof of delegation.
  • step G02 is not triggered by step E04, but performed independently of the verification method of a delegation according to the invention, or in a request delegChallengeQuery ('csp.com', options) previously performed by another terminal than the UA terminal.
  • Steps G02, F03, F04, F05 and G03 described below describe the method of producing a delegation certificate and are similar in synchronous or asynchronous mode.
  • the dCDN server connects to the CSP server via a secure connection of the TLS type where the two entities mutually authenticate each other, for example by exchanging X.509 certificates.
  • the dCDN server inserts, in a message that it sends to the CSP server, the DCQ delegation certificate request ('csp.com', options) received from the terminal in the TLS ClientHello () message.
  • the request for delegation can be transmitted using an application protocol such as http (especially in REST API mode), smtp or Idap.
  • the server CSP receives from the dCDN server the message sent during the step G02.
  • the server receiving this message may be a server of the domain 'csp.com' different from that which received in step F01 the content request from the terminal UA.
  • these two servers which are the same domain 'csp.com' and can be confused in one server, are both called "CSP server”.
  • This message includes a request for a certificate of delegation such as
  • • 'csp.com' is the name of the delegating domain, provided by the UA terminal;
  • the CSP server can obtain the CDN_OCSP_Stapling record directly from the TLS header, or obtain it by querying the CA that produced the X.509 certificate of the 'dCDN.com' domain.
  • the server CSP analyzes the received delegation certificate request.
  • the delegation certificate request further comprises a URL signature field added by uCDN prior to step E02, and that the UA terminal has transmitted to the dCDN server during of step E04.
  • the CSP server can verify that the uCDN server has actually delegated delivery of the content to another delivery server.
  • the CSP server can then verify the authenticity of the delegation certificate request, in order to identify that it comes from a known UA terminal. previously, or measure the redirection time when the delegation is multiple, to determine if the delivery of content by the dCDN server meets a minimum performance requirement.
  • the delegation certificate request further comprises an IP address of the terminal UA obtained by the CDN server during step G01. Since the IP address of the CDN server is visible from the CSP server, the CSP server is thus able to determine the respective geographical locations of the terminal UA and the CDN server, and to estimate the quality of service resulting from the broadcasting of the content MMContent of the dCDN server to the UA terminal. If this quality is considered insufficient by the CSP server, it may decide not to assign a delegation to the dCDN server.
  • the CSP server sends to the DCN server a delegation certificate response to the request issued during the step G02, which the DCN server receives during the step G03.
  • This response message takes the form of a response using the same protocol as the request:
  • DCA deleg_CSP_dCDN
  • the response message includes the delegation certificate signed by the CSP server:
  • CSP_OCSP_Stapling a recent OCSP record of the X.509 certificate of the CSP server previously obtained by the CSP server from a certification authority;
  • CSP calculates a fingerprint of the two records "dCDN_OCSP_Stapling” and "CSP_OCSP_Stapling” using a hash function (SHA256), which it signs using the private key of his X.509 certificate.
  • SHA256 hash function
  • the certificate of delegation If in the opposite case, for one reason or another, the CSP server has decided during the analysis step F04 to refuse to assign a delegation to the dCDN server, the response message may be empty, or include a token corresponding to a denial of delegation, signed using the private key of the X.509 certificate of 'csp.com'.
  • the response message may, in the case of a denial of delegation, include a link to a site or alternative server, which the CSP server trusts, and to which the UA terminal can go.
  • This alternative server can be for example a server more adapted to the type of terminal, in the case where the protocol used in the terminal UA and the server of CDN is the protocol QUIC (the server dCDN then adds the field UAID of the CHO, equivalent QUIC to TLS ClientHello message, in the DCQuery query).
  • the response message is a type of HTTPS redirect containing a URL, which has the advantage of constituting an alternative to a complete cancellation of the delivery by the DCN server of the requested content.
  • the dCDN server responds to the delegation certificate request that the UA terminal has issued during the step E04.
  • This response message may be for example a message according to a modification of the TLS protocol, such as:
  • This message includes the response to the delegation certificate request, signed by the CSP server, that the dCDN server received in step G03.
  • the terminal UA receives this message during a step E05.
  • the terminal UA verifies the signature of the delegation certificate: it decrypts the print at using the public key of the X.509 certificate of 'csp.com' received in step E02, and calculates a fingerprint using the same hash function as that used by the signer, and verifies that the decrypted fingerprint and the calculated fingerprint are very identical.
  • UA finalizes the establishment of the TLS tunnel with the DCN server, which allows the delivery of MMContent content from the DCN server to the UA terminal.
  • the UA terminal closes the TLS tunnel with the DCN server, and the MMContent content is not delivered to the UA terminal.
  • the UA terminal closes the TLS tunnel with the dCDN server, and issue a suitable request for it to be directed to the site or the alternative server.
  • FIG. 3 shows an example of a verification device structure of a delegation certificate 300, allowing the implementation of a verification method of a delegation certificate according to any one of the embodiments described above. in connection with Figure 2.
  • the validation device 300 comprises a random access memory 303 (for example a RAM memory), a processing unit 302, equipped for example with a processor, and controlled by a computer program stored in a read-only memory 301 (for example a ROM memory or a hard disk).
  • a computer program stored in a read-only memory 301 (for example a ROM memory or a hard disk).
  • the code instructions of the computer program are for example loaded into the RAM 303 before being executed by the processor of the processing unit 302.
  • FIG. 3 only illustrates a particular embodiment, among several possible specific embodiments, of the verification method of a delegation certificate detailed above, in relation to FIG. 2. Indeed, the technique of the invention is carried out indifferently on a reprogrammable computer PC computer, a DSP processor or a microcontroller) executing a program comprising a sequence of instructions, or on a dedicated computing machine (for example a set of logic gates such as an FPGA or an ASIC, or any other hardware module).
  • a reprogrammable computer PC computer for example a set of logic gates such as an FPGA or an ASIC, or any other hardware module.
  • the corresponding program (that is to say the sequence of instructions) may be stored in a removable storage medium or not, this storage medium being readable partially or totally by a computer or a processor.
  • the validation device also includes a communication module (COM) adapted to transmit content request messages, and connection establishment requests, and to receive redirection messages, and certification messages.
  • COM communication module
  • the processing unit comprises an Internet browser software module ("browser" in English) or HTTP client adapted to implement the verification process of a delegation certificate according to the invention. any of the particular modes described above.
  • FIG. 4 shows an exemplary production device structure of a delegation certificate 400, allowing the implementation of a method for producing a delegation certificate according to any one of the embodiments described above. in connection with Figure 2.
  • the device for producing a delegation certificate 400 comprises a random access memory 403 (for example a RAM memory), a processing unit 402, equipped for example with a processor, and controlled by a computer program stored in a memory 401 dead (for example a ROM or a hard disk).
  • a computer program stored in a memory 401 dead (for example a ROM or a hard disk).
  • the code instructions of the computer program are for example loaded into the RAM 403 before being executed by the processor of the processing unit 402.
  • FIG. 4 only illustrates one of several possible ways of implementing the method for producing a delegation certificate detailed above, in relation with FIG. 2. Indeed, the technique of the invention is realized.
  • a reprogrammable calculation machine a PC computer, a DSP processor or a microcontroller
  • a program comprising a sequence of instructions
  • a dedicated computing machine for example a set of logic gates such as an FPGA or an ASIC , or any other hardware module
  • the corresponding program (that is to say the sequence of instructions) may be stored in a removable storage medium or not, this storage medium being readable partially or totally by a computer or a processor.
  • the device for producing a delegation certificate also comprises a communication module (COM ') adapted to send delegation certificate response messages, and redirection messages, and to receive content request messages, and request messages for a delegation certificate.
  • COM ' communication module
  • such a device for producing a delegation certificate is included in a server, for example a server of a content provider able to reference said content.
  • FIG. 5 shows an exemplary request device structure of a delegation certificate 500, allowing the implementation of a method for requesting a delegation certificate according to any one of the embodiments described above. in connection with Figure 2.
  • the device for producing a delegation certificate 500 comprises a random access memory 503 (for example a RAM memory), a processing unit 502, equipped for example with a processor, and controlled by a computer program stored in a memory dead 501 (for example a ROM or a hard disk).
  • a computer program stored in a memory dead 501 for example a ROM or a hard disk.
  • the code instructions of the computer program are for example loaded into the RAM 503 before being executed by the processor of the processing unit 502.
  • FIG. 5 only illustrates one of several possible ways of implementing the method for requesting a delegation certificate detailed above, in relation to FIG. 2. Indeed, the technique of the invention is realized. indifferently on a reprogrammable calculation machine (a PC computer, a DSP processor or a microcontroller) executing a program comprising a sequence of instructions, or on a dedicated computing machine (for example a set of logic gates such as an FPGA or an ASIC , or any other hardware module).
  • a reprogrammable calculation machine a PC computer, a DSP processor or a microcontroller
  • a program comprising a sequence of instructions
  • a dedicated computing machine for example a set of logic gates such as an FPGA or an ASIC , or any other hardware module.
  • the corresponding program (that is to say the sequence of instructions) may be stored in a removable storage medium or not, this storage medium being readable partially or totally by a computer or a processor.
  • the request device for a delegation certificate also comprises a communication module (COM ") adapted to send request messages for a delegation certificate, and certification messages, and to receive certificate certificate response messages. delegation, and requests to establish a connection.
  • COM communication module
  • such a device for requesting a delegation certificate is included in a content distribution server, for example a cache server capable of broadcasting content.

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Databases & Information Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Graphics (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

L'invention concerne un procédé de vérification d'un certificat de délégation, la délégation étant d'un premier serveur (CSP) à un second serveur (dCDN), pour une livraison d'un contenu référencé sur le premier serveur, et destiné à un terminal client (UA), le procédé comprenant les étapes suivantes mises en œuvre par le terminal : · émission (E01 ) d'un premier message de requête du contenu, à destination du premier serveur, au travers d'une première connexion chiffrée entre le terminal et le premier serveur, au moyen de laquelle le terminal a préalablement obtenu une clé de chiffrement associée au premier serveur, • réception (E02) d'un message de redirection en provenance du premier serveur, comprenant au moins un identifiant d'un serveur tiers (dCDN, uCDN), • obtention (E03) d'une adresse du second serveur, à partir de l'au moins un identifiant reçu dans le message de redirection, • émission (E04) d'une demande d'établissement d'une seconde connexion chiffrée entre le terminal et le second serveur, comprenant un identifiant du premier serveur, • réception (E05) d'un message de certification en provenance du second serveur, comprenant un certificat de délégation signé par le premier serveur, au travers de la seconde connexion chiffrée, • vérification (E06) du certificat de délégation à l'aide de la clé de chiffrement associée au premier serveur, • émission (E07) d'un second message de requête du contenu, à destination du second serveur, au travers de la seconde connexion chiffrée, si le certificat de délégation vérifié est valable.

Description

Procédés et dispositifs de vérification de la validité d'une 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 par le biais du navigateur de son terminal client, 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 autre serveur, 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.
Malgré la sécurité apportée par TLS, le terminal client n'a aucun moyen de vérifier la validité de cette délégation. Ceci est d'autant plus problématique que les CDN (Content Delivery Network, réseau de distribution de contenu, en anglais), auxquels est déléguée la livraison du contenu, sont de plus en plus nombreux, et peuvent se déléguer entre eux la délégation qu'ils ont reçue d'un fournisseur de contenu, sans que ce dernier nécessairement le sache.
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 vient améliorer la situation à l'aide d'un procédé de vérification d'un certificat de délégation, la délégation étant d'un premier serveur à un second serveur, pour une livraison d'un contenu référencé sur le premier serveur, et destiné à un terminal client, le procédé comprenant les étapes suivantes mises en œuvre par le terminal :
• émission d'un premier message de requête du contenu, à destination du premier serveur, au travers d'une première connexion chiffrée entre le terminal et le premier serveur, au moyen de laquelle le terminal a préalablement obtenu une clé de chiffrement associée au premier serveur,
• réception d'un message de redirection, comprenant au moins un identifiant d'un serveur tiers,
· obtention d'une adresse du second serveur, à partir de l'au moins un identifiant reçu dans le message de redirection,
• émission d'une demande d'établissement d'une seconde connexion chiffrée entre le terminal et le second serveur, comprenant un identifiant du premier serveur.
Le procédé de vérification est particulier en ce qu'il comprend en outre les étapes suivantes :
• réception d'un message de certification en provenance du second serveur, comprenant un certificat de délégation signé par le premier serveur, au travers de la seconde connexion chiffrée,
• vérification du certificat de délégation à l'aide de la clé de chiffrement associée au premier serveur,
• émission d'un second message de requête du contenu, à destination du second serveur, au travers de la seconde connexion chiffrée, si le certificat de délégation vérifié est valable. Le procédé de vérification selon l'invention permet au terminal de vérifier si la délégation de livraison du contenu par une connexion chiffrée est bien valable.
Lorsqu'un terminal requiert un contenu à un serveur de contenu, et que ce serveur a délégué la livraison de ce contenu à un serveur tiers, le terminal reçoit du premier serveur un message de redirection comprenant un identifiant de ce serveur tiers, à qui il a délégué la livraison du contenu. Avec cet identifiant, le terminal obtient une adresse, qui peut être celle correspondant à l'identifiant, mais qui peut aussi être celle d'un autre serveur, à qui le serveur tiers a lui-même délégué son rôle. On parle alors de délégation multiple. Cette seconde délégation à cet autre serveur, en cascade de la première, peut se faire par exemple à l'aide d'une simple redirection DNS, invisible du premier serveur.
Dans la technique antérieure, par exemple basée sur https, sur le DNS, et sur un protocole de vérification de certificat tel que OCSP (Online Certificate Status Protocol, ou protocole de statut de certificat en ligne, en anglais) ou sa variante OCSP Stapling, le terminal peut s'assurer que tous les serveurs impliqués dans la chaîne de délégation sont authentifiés par une autorité de certification, mais rien ne lui permet de vérifier la validité de la seconde délégation, ou a fortiori la validité de toute délégation suivante, en cas de délégation multiple à plus de deux niveaux.
Grâce au procédé de vérification selon l'invention, le terminal reçoit du second serveur un certificat de délégation, lui permettant de décider d'accéder au contenu ou non, en fonction de sa vérification du certificat. Cette vérification se faisant à l'aide d'une clé publique propre au premier serveur, le terminal peut vérifier que le certificat de délégation reçu du second serveur a été établi avec l'accord du premier serveur.
Même dans le cas le plus simple, où il n'y a pas de délégation multiple en cascade, c'est-à-dire dans le cas où le second serveur qui livre le contenu est le serveur tiers connu du premier serveur, il se peut que la délégation ait été révoquée entretemps par le premier serveur, pour une raison quelconque. Grâce à ce procédé selon l'invention, le terminal peut vérifier que le certificat de délégation reçu du second serveur établi valablement à un instant donné avec l'accord du premier serveur, est encore valable à l'instant où le terminal requiert le contenu. De plus, dans ce cas, ce procédé donne une occasion au second serveur de renouveler son certificat de délégation auprès du premier serveur s'il est devenu trop ancien.
Selon un aspect de l'invention, l'étape d'obtention d'une adresse du second serveur comprend une étape de sélection de l'adresse parmi les identifiants de serveurs tiers, et/ou une étape d'interrogation d'un serveur de résolution d'adresse avec un identifiant.
Avantageusement, si le message de redirection en provenance du premier serveur comprend une liste d'identifiants ou d'adresses, le terminal peut en sélectionner une selon ses propres critères. De même si le message de redirection en provenance du premier serveur comprend un nom de domaine, le terminal peut obtenir une adresse à partir de ce nom en effectuant une requête DNS.
Selon un aspect de l'invention, le procédé comprend en outre une étape d'émission d'un second message de requête du contenu, à destination du second serveur, au travers de la seconde connexion chiffrée, si le certificat de délégation vérifié est valable.
Avantageusement, le terminal client consomme le contenu demandé au travers d'une connexion avec le second serveur, auquel le premier serveur a légitimement délégué la livraison.
Selon un aspect de l'invention, le message de certification comprend en outre une instruction de redirection et où le procédé comprend en outre une étape de redirection du terminal vers un troisième serveur.
Que le certificat de délégation soit valable ou non, c'est-à-dire que le premier serveur ait accepté ou non de déléguer la livraison au second serveur, le premier serveur peut inviter le terminal à se connecter à un serveur autre que le second serveur plutôt que de rester connecté au second serveur. Ce serveur de redirection peut être le premier serveur, ou un site ou un serveur déterminé par le premier serveur. Le site peut par exemple être une page d'information avertissant que le second serveur n'est pas un serveur approprié pour livrer le contenu demandé. Le serveur peut être un serveur de livraison alternatif, préférable au second serveur.
Les différents aspects du procédé de vérification qui viennent d'être décrits peuvent être mis en œuvre indépendamment les uns des autres ou en combinaison les uns avec les autres.
L'invention concerne aussi un procédé de production d'un certificat de délégation, la délégation étant d'un premier serveur à un second serveur, pour une livraison d'un contenu référencé sur le premier serveur, et destiné à un terminal client, le procédé comprenant les étapes suivantes mises en œuvre par le premier serveur: · réception d'un message de requête du contenu, en provenance du terminal, au travers d'une première connexion chiffrée entre le terminal et le premier serveur, au moyen de laquelle le terminal a préalablement obtenu une clé de chiffrement associée au premier serveur,
• émission d'un message de redirection à destination du terminal, comprenant au moins un identifiant d'un serveur tiers,
Le procédé de production est particulier en ce qu'il comprend en outre les étapes suivantes :
• réception d'un message de demande d'un certificat de délégation, en provenance d'un second serveur, comprenant un certificat d'authenticité du second serveur, · analyse de la demande d'un certificat de délégation,
• en fonction du résultat de l'analyse, émission d'un message de réponse de certificat de délégation, à destination du second serveur, comprenant un certificat de délégation signé par le premier serveur, vérifiable à l'aide de la clé de chiffrement.
Grâce au procédé de production selon l'invention, le premier serveur peut décider, si cela est approprié selon des critères propres au premier serveur, de fournir à un second serveur qui n'est pas forcément le serveur tiers auquel le premier serveur a éventuellement déjà délégué la livraison du contenu, une information concernant la délégation du premier au second serveur. Cette information ne peut pas être modifiée par le second serveur, mais peut être vérifiée par le terminal auquel le second serveur la transmet.
Selon un aspect de l'invention, le message de demande d'un certificat de délégation comprend en outre une adresse du terminal client.
Avantageusement, le premier serveur peut ainsi prendre en compte, lors de l'étape d'analyse, l'adresse du terminal demandant le contenu. Ceci est utile car avec l'adresse il est possible de déterminer la localisation géographique, et, connaissant celle du second serveur, le premier serveur peut déterminer si la distance entre le terminal et le second serveur est propice à une livraison satisfaisante du contenu.
Selon un aspect de l'invention, le message de demande d'un certificat de délégation comprend en outre une signature du serveur tiers.
Avantageusement, le premier serveur peut ainsi prendre en compte, lors de l'étape d'analyse, la signature du serveur tiers. Ceci est utile car ce serveur tiers dispose normalement d'une délégation valable de la part du premier serveur, ou en a en tout cas déjà disposé. Le second serveur peut donc déduire que le second serveur a obtenu une délégation du serveur tiers, ce qui renforce la légitimité du second serveur auprès du premier serveur.
Selon un aspect de l'invention, le message de réponse de certificat de délégation comprend en outre une instruction de redirection pour le terminal client.
Que le premier serveur ait décidé ou non de déléguer la livraison au second serveur, le premier serveur peut inviter le terminal à se connecter à un site déterminé par le premier serveur, plutôt que de rester connecté au second serveur. Ce site peut par exemple être une page d'information avertissant que le second serveur n'est pas un serveur approprié pour livrer le contenu demandé, ou être un serveur de livraison alternatif, préférable au second serveur par exemple en raison de performances supérieures.
Les différents aspects du procédé de production qui viennent d'être décrits peuvent être mis en œuvre indépendamment les uns des autres ou en combinaison les uns avec les autres.
L'invention concerne encore un procédé de demande d'un certificat de délégation, la délégation étant d'un premier serveur à un second serveur, pour une livraison d'un contenu référencé sur le premier serveur, et destiné à un terminal client (UA), le procédé comprenant les étapes suivantes mises en œuvre par le second serveur :
• réception d'une demande d'établissement d'une seconde connexion chiffrée entre le terminal et le second serveur, comprenant un identifiant du premier serveur.
Le procédé de demande est particulier en ce qu'il comprend en outre les étapes suivantes :
• émission d'un message de demande d'un certificat de délégation, à destination du premier serveur, comprenant un certificat d'authenticité du second serveur, · réception d'un message de réponse de certificat de délégation, en provenance du premier serveur, comprenant un certificat de délégation signé par le premier serveur, vérifiable à l'aide d'une clé de chiffrement associée au premier serveur,
• émission d'un message de certification à destination du terminal, comprenant le certificat de délégation, au travers de la seconde connexion chiffrée, le terminal ayant préalablement obtenu une clé de chiffrement associée au premier serveur, au moyen d'une première connexion chiffrée entre le terminal et le premier serveur. Ainsi, lorsque le second serveur reçoit une demande d'établissement d'une connexion d'un terminal souhaitant consommer un contenu référencé sur le premier serveur, le second serveur est en mesure de prouver qu'il a obtenu une délégation valable de la part du premier serveur.
L'invention concerne encore un dispositif de vérification d'un certificat de délégation, la délégation étant d'un premier serveur à un second serveur, pour une livraison d'un contenu référencé sur le premier serveur, et destiné à un terminal client, le dispositif comprenant une machine de calcul reprogrammable ou une machine de calcul dédiée, apte à et configurée pour :
• émettre un premier message de requête du contenu, à destination du premier serveur, au travers d'une première connexion chiffrée entre le terminal et le premier serveur, au moyen de laquelle le terminal a préalablement obtenu une clé de chiffrement associée au premier serveur,
• recevoir un message de redirection en provenance du premier serveur, comprenant au moins un identifiant d'un serveur tiers,
• obtenir une adresse du second serveur, à partir de l'au moins un identifiant reçu dans le message de redirection,
· émettre une demande d'établissement d'une seconde connexion chiffrée entre le terminal et le second serveur, comprenant un identifiant du premier serveur,
• recevoir un message de certification en provenance du second serveur, comprenant un certificat de délégation signé par le premier serveur, au travers de la seconde connexion chiffrée,
· vérifier le certificat de délégation à l'aide de la clé de chiffrement associée au premier serveur,
• émettre un second message de requête du contenu, à destination du second serveur, au travers de la seconde connexion chiffrée, si le certificat de délégation vérifié est valable.
Ce dispositif de vérification, apte à mettre en œuvre dans tous ses modes de réalisation le procédé de vérification qui vient d'être décrit, est destiné à être mis en œuvre dans un terminal client ou dans une application comprise dans le terminal telle qu'un navigateur (browser en anglais). L'invention concerne encore un dispositif de production d'un certificat de délégation, la délégation étant d'un premier serveur à un second serveur, pour une livraison d'un contenu référencé sur le premier serveur, et destiné à un terminal client, le dispositif comprenant une machine de calcul reprogrammable ou une machine de calcul dédiée, apte à et configurée pour :
· recevoir un message de requête du contenu, en provenance du terminal, au travers d'une première connexion chiffrée entre le terminal et le premier serveur, au moyen de laquelle le terminal a préalablement obtenu une clé de chiffrement associée au premier serveur,
• émettre un message de redirection à destination du terminal, comprenant au moins un identifiant d'un serveur tiers,
• recevoir un message de demande d'un certificat de délégation, en provenance d'un second serveur, comprenant un certificat d'authenticité du second serveur,
• analyser la demande d'un certificat de délégation,
• en fonction du résultat de l'analyse, émettre un message de réponse de certificat de délégation, à destination du second serveur, comprenant un certificat de délégation signé par le premier serveur, vérifiable à l'aide de la clé de chiffrement. Ce dispositif de production, apte à mettre en œuvre dans tous ses modes de réalisation le procédé de production qui vient d'être décrit, est destiné à être mis en œuvre par exemple dans un serveur de référencement de contenu.
L'invention concerne aussi un dispositif de demande d'un certificat de délégation, la délégation étant d'un premier serveur à un second serveur, pour une livraison d'un contenu référencé sur le premier serveur, et destiné à un terminal client, 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 seconde connexion chiffrée entre le terminal et le second serveur, comprenant un identifiant du premier serveur,
• émettre un message de demande d'un certificat de délégation, à destination du premier serveur, comprenant un certificat d'authenticité du second serveur, · recevoir un message de réponse de certificat de délégation, en provenance du premier serveur, comprenant un certificat de délégation signé par le premier serveur, vérifiable à l'aide d'une clé de chiffrement associée au premier serveur,
• émettre un message de certification à destination du terminal, comprenant le certificat de délégation, au travers de la seconde connexion chiffrée, le terminal ayant préalablement obtenu une clé de chiffrement associée au premier serveur, au moyen d'une première connexion chiffrée entre le terminal et le premier serveur. Ce dispositif de demande, apte à mettre en œuvre dans tous ses modes de réalisation le procédé de demande qui vient d'être décrit, est destiné à être mis en œuvre par exemple dans un serveur de diffusion de contenu.
L'invention concerne aussi un système de vérification d'un certificat de délégation, comprenant un dispositif de vérification, un dispositif de production et un dispositif de demande d'un certificat de délégation. L'invention vise enfin :
• un programme d'ordinateur comprenant des instructions pour la mise en œuvre des étapes du procédé de vérification qui vient d'être décrit, lorsque ce programme est exécuté par un processeur, ainsi qu'un support d'informations lisible par un terminal client, et comportant des instructions de ce programme d'ordinateur, · un programme d'ordinateur comprenant des instructions pour la mise en œuvre des étapes du procédé de production 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,
· un programme d'ordinateur comprenant des instructions pour la mise en œuvre des étapes du procédé de demande 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.
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 œuvre des étapes du procédé de demande d'un certificat de délégation, du procédé de vérification d'un certificat de délégation et du procédé de production d'un certificat de délégation, selon un aspect de l'invention,
• la figure 3 présente un exemple de structure d'un dispositif de vérification d'un certificat de délégation, selon un aspect de l'invention,
• la figure 4 présente un exemple de structure d'un dispositif de production d'un certificat de délégation, selon un aspect de l'invention,
• la figure 5 présente un exemple de structure d'un dispositif de demande d'un certificat 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 et QU IC.
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'enchaînement et de mise en œuvre des étapes du procédé de demande d'un certificat de délégation, du procédé de vérification d'un certificat de délégation et du procédé de production d'un certificat 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 récupère 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 il peut représenter 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 fait suite à 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, ou encore un ticket de session SessionTicket (tel que décrit dans le RFC5077). La clé publique est en général attachée à un certificat du serveur CSP, que le serveur CSP a obtenu après d'une autorité de certification quelconque. Ce matériel 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'
Lors d'une étape F01 , connue, le serveur CSP reçoit la requête http GET et identifie un serveur tiers, avec lequel une relation d'ordre contractuel existe. Ce serveur 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.
Lors d'une étape F02, connue, L'UA est redirigé de proche en proche vers le serveur en charge d'effectuer la livraison du contenu.
Dans le cas où la délégation est simple, le serveur tiers est celui qui effectue la livraison du contenu au terminal UA. Le serveur tiers est alors le serveur dCDN.
Dans le cas où la délégation est multiple, c'est-à-dire le cas où le serveur tiers n'effectue pas la livraison du contenu mais l'a déléguée à un autre serveur, le serveur tiers est le serveur uCDN et cet autre serveur est le serveur dCDN.
Dans le cas à délégation simple, lors de l'étape F02, le serveur CSP émet aussi vers le terminal UA un message de redirection en réponse à la requête "http GET https://csp.com/MMContent", comprenant l'adresse du serveur dCDN, "dcdn.com". Ce message de redirection est par exemple :
"http 302 redirect https://dcdn.com/MMContent",
que le terminal UA reçoit lors d'une étape E02.
Dans le cas à délégation multiple, 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 du serveur dCDN, sous forme d'adresse url ou d'adresse IP. Le message de redirection émis lors de l'étape F02 est alors, par exemple :
"http 302 redirect https://dcdn.com/MMContent",
que le terminal UA reçoit lors de l'étape E02.
Dans ce cas, lors d'une étape E03, le terminal UA obtient l'adresse IP du serveur dCDN par une requête DNS sur le nom de domaine "dcdn.com".
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 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-encoding-08.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 'dCDN.com' et de l'adresse IP d'un serveur de 'dCDN.com', le serveur dCDN.
Lorsque le terminal UA a obtenu l'adresse 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, ce message est émis par le terminal UA, reçu par le serveur dCDN lors d'une étape G01 , comprenant, dans un mode préféré de réalisation de l'invention, une requête au serveur dCDN de prouver qu'il a obtenu une délégation valable de la part d'un serveur du domaine 'csp.com'. Ce message peut être par exemple un message selon une modification du protocole TLS, comprenant une requête de certificat de délégation DCQ (pour Délégation Challenge Query, ou requête de preuve de délégation, en anglais), tel que :
"TLS ClientHello (DCQ('csp.com', options) ; SNI='dCDN.com')".
Optionnellement, le contenu du message est signé à l'aide d'une clé préalablement obtenue par le terminal UA, comme par exemple une clé de type SessionTicket, afin que le serveur dCDN ne puisse pas modifier le contenu de la requête DCQ.
Afin d'obtenir cette preuve exigée par le terminal UA, appelée certificat de délégation, le serveur dCDN doit la requérir, ou l'avoir préalablement requise, de la part du domaine 'csp.com'.
Dans un mode dit synchrone, la requête de certificat de délégation émise par le serveur dCDN lors d'une étape G02 est déclenchée par l'étape E04. Ce mode est utile lorsque par exemple aucune relation n'existe préalablement entre le serveur CSP et le serveur dCDN, ou lorsque le certificat de délégation en possession du serveur dCDN est ancien et doit être renouvelé. Dans ce mode, optionnellement, le terminal UA peut insérer une information reçue au préalable, tel que par exemple :
· une signature de l'URL de redirection insérée par le serveur uCDN, dont le but est de prouver au serveur dCDN que la requête reçue du terminal UA provient effectivement d'une redirection initiée par le serveur uCDN; • un SessionTicket reçu du serveur CSP, dont le but est de permettre la
reprise rapide d'une connexion TLS entre le terminal UA et le serveur CSP. Dans un second mode de réalisation de l'invention, dit mode asynchrone, le serveur dCDN requiert périodiquement ce certificat de délégation, indépendamment de l'étape E04, afin d'être prêt à fournir à tout moment, sur demande d'un terminal tel que le terminal UA, une preuve de délégation récente. Dans ce mode asynchrone l'étape G02 n'est pas déclenchée par l'étape E04, mais effectuée indépendamment du procédé de vérification d'une délégation selon l'invention, ou encore dans une requête delegChallengeQuery('csp.com', options) effectuée préalablement par un autre terminal que le terminal UA.
Les étapes G02, F03, F04, F05 et G03, décrites ci-dessous décrivent le procédé de production d'un certificat de délégation et sont similaires en mode synchrone ou asynchrone.
Lors de l'étape G02, le serveur dCDN se connecte au server CSP via une connexion sécurisé de type TLS où les 2 entités s'authentifient mutuellement par exemple en échangeant des certificats X.509. Le serveur dCDN insère, dans un message qu'il émet vers le serveur CSP, la demande de certificat de délégation DCQ('csp.com', options) reçue du terminal dans le message TLS ClientHello(). Optionnellement la demande de délégation peut être transmise à l'aide d'un protocole applicatif tel que http (notamment en mode API REST), smtp ou Idap.
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é ces deux serveurs, qui sont du même domaine 'csp.com' et peuvent être confondus en un seul serveur, sont appelé tous les deux "serveur CSP".
Ce message comprend une requête de certificat de délégation telle que
"DCQ('csp.com', options)",
comprenant par exemple :
• 'csp.com' est le nom du domaine délégant, fourni par le terminal UA;
• "options" comprend un enregistrement OCSP du certificat X.509 de dCDN obtenu préalablement par le serveur dCDN auprès d'une autorité de certification, noté "dCDN_OCSP_Stapling"
Optionnellement le serveur CSP peut obtenir directement de l'entête TLS l'enregistrement dCDN_OCSP_Stapling, ou l'obtenir en interrogeant l'autorité de certification qui a produit le certificat X.509 du domaine 'dCDN.com'.
Lors d'une étape F04, le serveur CSP analyse la demande de certificat de délégation reçue. Optionnellement, en mode synchrone, au cas où la délégation est multiple, la demande de certificat de délégation comprend en outre un champ 'URL Signing' ajouté par uCDN préalablement à l'étape E02, et que le terminal UA a transmis au serveur dCDN lors de l'étape E04. Ainsi, le serveur CSP peut vérifier que le serveur uCDN a effectivement délégué la livraison du contenu à un autre serveur de livraison.
Optionnellement, en mode synchrone, au cas où un champ SessionTicket est compris dans la requête DCQ, le serveur CSP peut alors vérifier l'authenticité de la requête de certificat de délégation, afin d'identifier qu'elle provient d'un terminal UA connu préalablement, ou mesurer le temps de redirection quand la délégation est multiple, afin de déterminer si la livraison de contenu par le serveur dCDN satisfait une exigence de performance minimale.
Optionnellement, en mode synchrone, la demande de certificat de délégation comprend en outre une adresse IP du terminal UA obtenue par le serveur dCDN lors de l'étape G01. L'adresse IP du serveur dCDN étant visible du serveur CSP, le serveur CSP est ainsi en mesure de déterminer les localisations géographiques respectives du terminal UA et du serveur dCDN, et d'estimer la qualité de service résultant de la diffusion du contenu MMContent du serveur dCDN vers le terminal UA. Si cette qualité est jugée insuffisante par le serveur CSP, il peut décider de ne pas attribuer de délégation au serveur dCDN.
Lors d'une étape F05, le serveur CSP émet vers le serveur dCDN une réponse de certificat de délégation à la demande émise lors de l'étape G02, que le serveur dCDN reçoit lors de l'étape G03. Ce message de réponse prend la forme d'une réponse utilisant le même protocole que la requête :
"DCA(deleg_CSP_dCDN)".
Si le serveur CSP, lors de l'étape d'analyse F04, a décidé d'autoriser la délégation de la livraison du contenu au serveur dCDN, le message de réponse comprend le certificat de délégation signé par le serveur CSP :
• "dCDN_OCSP_Stapling": l'enregistrement récent OCSP du certificat X.509 du serveur dCDN ;
· "CSP_OCSP_Stapling": un enregistrement récent OCSP du certificat X.509 du serveur CSP obtenu préalablement par le serveur CSP auprès d'une autorité de certification;
• une signature par le serveur CSP du certificat de délégation: CSP calcule une empreinte des deux enregistrements "dCDN_OCSP_Stapling" et "CSP_OCSP_Stapling" à l'aide d'une fonction de hashage (SHA256), qu'il signe à l'aide de la clé privée de son certificat X.509 .
Ces trois éléments constituent ce qui est appelé le certificat de délégation. Si dans le cas contraire, pour une raison ou une autre, le serveur CSP a décidé lors de l'étape d'analyse F04 de refuser d'attribuer une délégation au serveur dCDN, le message de réponse peut être vide, ou comprendre un jeton correspondant à un refus de délégation, signé à l'aide de la clé privée du certificat X.509 de 'csp.com'.
Dans une variante avantageuse, le message de réponse peut, dans le cas d'un refus de délégation, comprendre un lien vers un site ou un serveur alternatif, auquel le serveur CSP fait confiance, et vers lequel le terminal UA peut se diriger. Ce serveur alternatif peut être par exemple un serveur plus adapté au type de terminal, dans le cas où le protocole utilisé en le terminal UA et le serveur dCDN est le protocole QUIC (le serveur dCDN ajoute alors le champ UAID du CHO, équivalent QUIC au message TLS ClientHello, dans la requête DCQuery). Dans ce cas le message de réponse est un type de redirection HTTPS contenant une URL, ce qui présente l'avantage de constituer une solution de remplacement à une annulation complète de la livraison par le serveur dCDN du contenu demandé.
Lors d'une étape G04, le serveur dCDN répond à la demande de certificat de délégation que le terminal UA a émise lors de l'étape E04. Ce message de réponse peut être par exemple un message selon une modification du protocole TLS, tel que :
"TLS ServerHello (DCA(deleg_CSP_dCDN))",
ou "TLS ServerHello (DCA(PoD))".
Ce message comprend la réponse à la requête de certificat de délégation, signée par le serveur CSP, que le serveur dCDN a reçue lors de l'étape G03.
Le terminal UA reçoit ce message lors d'une étape E05. Lors d'une étape E06, le terminal UA vérifie la signature du certificat de délégation : il déchiffre l'empreinte à l'aide de la clé publique du certificat X.509 de 'csp.com' reçue lors de l'étape E02, et calcule une empreinte à l'aide de la même fonction de hachage que celle utilisée par le signataire, et vérifie que l'empreinte déchiffrée et l'empreinte calculée sont bien identiques.
Si le certificat de délégation est authentique, lors d'une étape E07, le terminal
UA finalise l'établissement du tunnel TLS avec le serveur dCDN, ce qui permet la livraison du contenu MMContent du serveur dCDN au terminal UA.
Si le certificat de délégation n'est pas valable, lors d'une étape E08, le terminal UA ferme le tunnel TLS avec le serveur dCDN, et le contenu MMContent n'est pas livré au terminal UA.
Dans une variante avantageuse, si la signature du certificat de délégation est authentique et que le message de réponse contient une instruction de redirection vers un site ou un serveur alternatif, alors, lors d'une étape E09, le terminal UA ferme le tunnel TLS avec le serveur dCDN, et émet une requête adaptée afin qu'il soit dirigé vers le site ou le serveur alternatif.
La figure 3 présente un exemple de structure de dispositif de vérification d'un certificat de délégation 300, permettant la mise en œuvre d'un procédé de vérification d'un certificat 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 validation 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 vérification d'un certificat 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 validation comprend également un module de communication (COM) adapté pour émettre des messages de requête de contenu, et des demandes d'établissement de connexion, et pour recevoir des messages de redirection, et des messages de certification.
Selon un mode particulier de réalisation de l'invention, l'unité de traitement comprend un module logiciel de navigation Internet ("browser" en anglais) ou client HTTP adapté à mettre en œuvre le procédé de vérification d'un certificat de délégation selon l'un quelconque des modes particuliers décrits précédemment.
Selon un mode de réalisation, un tel dispositif de vérification d'un certificat de délégation est compris dans un terminal client. La figure 4 présente un exemple de structure de dispositif de production d'un certificat de délégation 400, permettant la mise en œuvre d'un procédé de production d'un certificat 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 production d'un certificat 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 production d'un certificat 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 production d'un certificat de délégation comprend également un module de communication (COM') adapté pour émettre des messages de réponse de certificat de délégation, et des messages de redirection, et pour recevoir des messages de requête de contenu, et des messages de demande d'un certificat de délégation.
Dans un mode de réalisation, un tel dispositif de production d'un certificat de délégation est compris dans un serveur, par exemple un serveur d'un fournisseur de contenu apte à référencer ledit contenu.
La figure 5 présente un exemple de structure de dispositif de demande d'un certificat de délégation 500, permettant la mise en œuvre d'un procédé de demande d'un certificat 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 production d'un certificat de délégation 500 comprend une mémoire vive 503 (par exemple une mémoire RAM), une unité de traitement 502, équipée par exemple d'un processeur, et pilotée par un programme d'ordinateur stocké dans une mémoire morte 501 (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 503 avant d'être exécutées par le processeur de l'unité de traitement 502.
La figure 5 illustre seulement une manière particulière, parmi plusieurs possibles, de mise en œuvre le procédé de demande d'un certificat 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 d'un certificat de délégation comprend également un module de communication (COM") adapté pour émettre des messages de demande d'un certificat de délégation, et des messages de certification, et pour recevoir des messages de réponse de certificat de délégation, et des demandes d'établissement d'une connexion.
Dans un mode de réalisation, un tel dispositif de demande d'un certificat de délégation est compris dans un serveur de diffusion de contenu, par exemple un serveur de cache apte à diffuser du contenu.

Claims

REVENDICATIONS
1. Procédé de vérification d'un certificat de délégation, la délégation étant d'un premier serveur (CSP) à un second serveur (dCDN), pour une livraison d'un contenu référencé sur le premier serveur, et destiné à un terminal client (UA),
le procédé comprenant les étapes suivantes mises en œuvre par le terminal :
• émission (E01 ) d'un premier message de requête du contenu, à destination du premier serveur, au travers d'une première connexion chiffrée entre le terminal et le premier serveur, au moyen de laquelle le terminal a préalablement obtenu une clé de chiffrement associée au premier serveur,
• réception (E02) d'un message de redirection, comprenant au moins un identifiant d'un serveur tiers (dCDN, uCDN),
• obtention (E03) d'une adresse du second serveur, à partir de l'au moins un identifiant reçu dans le message de redirection,
· émission (E04) d'une demande d'établissement d'une seconde connexion chiffrée entre le terminal et le second serveur, comprenant un identifiant du premier serveur,
le procédé étant caractérisé en ce qu'il comprend en outre les étapes suivantes :
• réception (E05) d'un message de certification en provenance du second serveur, comprenant un certificat de délégation signé par le premier serveur, au travers de la seconde connexion chiffrée,
• vérification (E06) du certificat de délégation à l'aide de la clé de chiffrement associée au premier serveur,
• émission (E07) d'un second message de requête du contenu, à destination du second serveur, au travers de la seconde connexion chiffrée, si le certificat de délégation vérifié est valable.
2. Procédé de vérification selon la revendication 1 , où l'étape d'obtention d'une adresse du second serveur comprend une étape de sélection de l'adresse parmi les identifiants de serveurs tiers, et/ou une étape d'interrogation d'un serveur de résolution d'adresse avec un identifiant.
3. Procédé de vérification selon l'une des revendications précédentes, comprenant en outre une étape d'émission (E07) d'un second message de requête du contenu, à destination du second serveur, au travers de la seconde connexion chiffrée, si le certificat de délégation vérifié est valable.
4. Procédé de vérification selon l'une des revendications précédentes, où le message de certification comprend en outre une instruction de redirection et où le procédé comprend en outre une étape de redirection (E09) du terminal vers un troisième serveur.
5. Procédé de production d'un certificat de délégation, la délégation étant d'un premier serveur (CSP) à un second serveur (dCDN), pour une livraison d'un contenu référencé sur le premier serveur, et destiné à un terminal client (UA),
le procédé comprenant les étapes suivantes mises en œuvre par le premier serveur:
• réception (F01 ) d'un message de requête du contenu, en provenance du terminal, au travers d'une première connexion chiffrée entre le terminal et le premier serveur, au moyen de laquelle le terminal a préalablement obtenu une clé de chiffrement associée au premier serveur,
• émission (F02) d'un message de redirection à destination du terminal, comprenant au moins un identifiant d'un serveur tiers (dCDN, uCDN),
le procédé étant caractérisé en ce qu'il comprend en outre les étapes suivantes :
• réception (F03) d'un message de demande d'un certificat de délégation, en provenance d'un second serveur, comprenant un certificat d'authenticité du second serveur,
• analyse (F04) de la demande d'un certificat de délégation,
• en fonction du résultat de l'analyse, émission (F05) d'un message de réponse de certificat de délégation, à destination du second serveur, comprenant un certificat de délégation signé par le premier serveur, vérifiable à l'aide de la clé de chiffrement.
6. Procédé de production selon la revendication précédente, où le message de demande d'un certificat de délégation comprend en outre une adresse du terminal client (UA).
7. Procédé de production selon l'un des revendications 5 à 6, où le message de demande d'un certificat de délégation comprend en outre une signature du serveur tiers (uCDN).
8. Procédé de production selon l'une des revendications 5 à 7, où le message de réponse de certificat de délégation comprend en outre une instruction de redirection pour le terminal client.
9. Dispositif de vérification d'un certificat de délégation, la délégation étant d'un premier serveur (CSP) à un second serveur (dCDN), pour une livraison d'un contenu référencé sur le premier serveur, et destiné à un terminal client (UA), le dispositif comprenant une machine de calcul reprogrammable (302) ou une machine de calcul dédiée, apte à et configurée pour :
· émettre un premier message de requête du contenu, à destination du premier serveur, au travers d'une première connexion chiffrée entre le terminal et le premier serveur, au moyen de laquelle le terminal a préalablement obtenu une clé de chiffrement associée au premier serveur,
• recevoir un message de redirection, comprenant au moins un identifiant d'un serveur tiers (dCDN, uCDN),
• obtenir une adresse du second serveur, à partir de l'au moins un identifiant reçu dans le message de redirection,
• émettre une demande d'établissement d'une seconde connexion chiffrée entre le terminal et le second serveur, comprenant un identifiant du premier serveur, le dispositif étant caractérisé en ce que ladite machine de calcul reprogrammable (302) ou ladite machine de calcul dédiée, est en outre apte à et configurée pour :
• recevoir un message de certification en provenance du second serveur, comprenant un certificat de délégation signé par le premier serveur, au travers de la seconde connexion chiffrée,
· vérifier le certificat de délégation à l'aide de la clé de chiffrement associée au premier serveur,
• émettre un second message de requête du contenu, à destination du second serveur, au travers de la seconde connexion chiffrée, si le certificat de délégation vérifié est valable.
10. Dispositif de production d'un certificat de délégation, la délégation étant d'un premier serveur (CSP) à un second serveur (dCDN), pour une livraison d'un contenu référencé sur le premier serveur, et destiné à un terminal client (UA), le dispositif comprenant une machine de calcul reprogrammable (402) ou une machine de calcul dédiée, apte à et configurée pour :
• recevoir un message de requête du contenu, en provenance du terminal, au travers d'une première connexion chiffrée entre le terminal et le premier serveur, au moyen de laquelle le terminal a préalablement obtenu une clé de chiffrement associée au premier serveur,
· émettre un message de redirection à destination du terminal, comprenant au moins un identifiant d'un serveur tiers (dCDN, uCDN),
le dispositif étant caractérisé en ce que ladite machine de calcul reprogrammable (402) ou ladite machine de calcul dédiée, est en outre apte à et configurée pour :
• recevoir un message de demande d'un certificat de délégation, en provenance d'un second serveur, comprenant un certificat d'authenticité du second serveur,
• analyser la demande d'un certificat de délégation,
• en fonction du résultat de l'analyse, émettre un message de réponse de certificat de délégation, à destination du second serveur, comprenant un certificat de délégation signé par le premier serveur, vérifiable à l'aide de la clé de chiffrement.
11. Système de vérification d'un certificat de délégation comprenant un dispositif conforme à la revendication 9, un dispositif conforme à la revendication 10 et un dispositif de demande d'un certificat de délégation, la délégation étant d'un premier serveur (CSP) à un second serveur (dCDN), pour une livraison d'un contenu référencé sur le premier serveur, et destiné à un terminal client (UA), le dispositif de demande comprenant une machine de calcul reprogrammable (502) ou une machine de calcul dédiée, apte à et configurée pour :
• recevoir une demande d'établissement d'une seconde connexion chiffrée entre le terminal et le second serveur, comprenant un identifiant du premier serveur, le système étant en outre caractérisé en ce que ladite machine de calcul reprogrammable (502) ou ladite machine de calcul dédiée, est en outre apte à et configurée pour :
• émettre un message de demande d'un certificat de délégation, à destination du premier serveur, comprenant un certificat d'authenticité du second serveur, · recevoir un message de réponse de certificat de délégation, en provenance du premier serveur, comprenant un certificat de délégation signé par le premier serveur, vérifiable à l'aide d'une clé de chiffrement associée au premier serveur,
• émettre un message de certification à destination du terminal, comprenant le certificat de délégation, au travers de la seconde connexion chiffrée, le terminal ayant préalablement obtenu une clé de chiffrement associée au premier serveur, au moyen d'une première connexion chiffrée entre le terminal et le premier serveur.
12. Produit programme d'ordinateur, comprenant des instructions de code de programme pour la mise en œuvre du procédé de vérification d'un certificat de délégation selon l'une quelconque des revendications 1 à 4, lorsque ledit programme est exécuté sur un ordinateur.
13. Support d'enregistrement lisible par un terminal client (UA) sur lequel est enregistré le programme selon la revendication 12.
14. Produit programme d'ordinateur, comprenant des instructions de code de programme pour la mise en œuvre du procédé de production d'un certificat de délégation selon l'une quelconque des revendications 5 à 8, lorsque ledit programme est exécuté sur un ordinateur.
15. Support d'enregistrement lisible par un serveur de contenu (CSP) sur lequel est enregistré le programme selon la revendication 14.
EP18704274.2A 2017-01-16 2018-01-16 Procédés et dispositifs de vérification de la validité d'une délégation de diffusion de contenus chiffrés Pending EP3568989A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1750326A FR3062013A1 (fr) 2017-01-16 2017-01-16 Procedes et dispositifs de verification de la validite d'une delegation de diffusion de contenus chiffres
PCT/FR2018/050100 WO2018130796A1 (fr) 2017-01-16 2018-01-16 Procédés et dispositifs de vérification de la validité d'une délégation de diffusion de contenus chiffrés

Publications (1)

Publication Number Publication Date
EP3568989A1 true EP3568989A1 (fr) 2019-11-20

Family

ID=59152968

Family Applications (1)

Application Number Title Priority Date Filing Date
EP18704274.2A Pending EP3568989A1 (fr) 2017-01-16 2018-01-16 Procédés et dispositifs de vérification de la validité d'une délégation de diffusion de contenus chiffrés

Country Status (4)

Country Link
US (1) US10979750B2 (fr)
EP (1) EP3568989A1 (fr)
FR (1) FR3062013A1 (fr)
WO (1) WO2018130796A1 (fr)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10956551B2 (en) * 2017-08-07 2021-03-23 Clarius Mobile Health Corp. Systems and methods for securing operation of an ultrasound scanner
US11171943B1 (en) * 2018-03-15 2021-11-09 F5 Networks, Inc. Methods for adding OCSP stapling in conjunction with generated certificates and devices thereof
FR3091097A1 (fr) * 2018-12-19 2020-06-26 Orange 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
FR3108816A1 (fr) * 2020-03-24 2021-10-01 Orange Procédé de délégation d’une fonction de résolution d’identifiants de nommage

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100299525A1 (en) * 2005-08-10 2010-11-25 Riverbed Technology, Inc. Method and apparatus for split-terminating a secure network connection, with client authentication

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
ATE241820T1 (de) * 2001-07-12 2003-06-15 Castify Networks Sa Verfahren zum bereitstellen von kundenzugriff auf einen inhaltanbietenden server unter kontrolle eines resoursenlokalisierenden servers

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100299525A1 (en) * 2005-08-10 2010-11-25 Riverbed Technology, Inc. Method and apparatus for split-terminating a secure network connection, with client authentication

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
ANONYMOUS: "Transport Layer Security - Wikipedia", 9 January 2017 (2017-01-09), XP093109796, Retrieved from the Internet <URL:https://en.wikipedia.org/w/index.php?title=Transport_Layer_Security&oldid=759082389> [retrieved on 20231206] *
See also references of WO2018130796A1 *

Also Published As

Publication number Publication date
US10979750B2 (en) 2021-04-13
WO2018130796A1 (fr) 2018-07-19
FR3062013A1 (fr) 2018-07-20
US20190387264A1 (en) 2019-12-19

Similar Documents

Publication Publication Date Title
EP2514166B1 (fr) Accès a un réseau de distribution de contenu numérique
FR3015832A1 (fr) Technique de controle du routage d&#39;une requete relative a un service
EP3568989A1 (fr) Procédés et dispositifs de vérification de la validité d&#39;une délégation de diffusion de contenus chiffrés
EP3643044A1 (fr) Procédé d&#39;activation de traitements appliqués à une session de données
EP3568966B1 (fr) Procédés et dispositifs de délégation de diffusion de contenus chiffrés
EP3560163B1 (fr) Validation de livraison de contenu et de verification d&#39;une delegation de livraison d&#39;un contenu
EP3900306B1 (fr) Procédé de détermination d&#39;une chaîne de délégation associée à une résolution d&#39;un nom de domaine dans un réseau de communication
WO2024083694A1 (fr) Procédé de traitement d&#39;une requête en résolution d&#39;au moins un identifiant de nommage, dispositif et programme d&#39;ordinateur correspondants
EP3900305A1 (fr) Procédé d&#39;acquisition d&#39;une chaîne de délégation relative à la résolution d&#39;un identifiant de nom de domaine dans un réseau de communication
EP4173252B1 (fr) Procédés et dispositifs de controle d&#39;accès à un contenu mémorisé par un serveur cache
EP3149902B1 (fr) Technique d&#39;obtention d&#39;une politique de routage de requêtes émises par un module logiciel s&#39;exécutant sur un dispositif client
EP4128717B1 (fr) Délégation d&#39;une fonction de résolution d&#39;identifiants de nommage
EP2446608B1 (fr) Technique de contrôle d&#39;accès par une entité cliente à un service
WO2025125235A1 (fr) Procédé de détermination d&#39;un ensemble de flux multicast auxquels un terminal récepteur est habilité à accéder
EP4158872A1 (fr) Procede de delegation de la livraison de contenus a un serveur cache
EP4595408A1 (fr) Procedes de resolution de nom, de communication, de traitement de messages et serveur, dispositif client et noeud relais correspondants
FR3145253A1 (fr) Procédé de révocation d’un jeton de certification permettant d’authentifier l’établissement d’une connexion entre deux équipements de communication, dispositifs et programmes d’ordinateur correspondants
EP3643035A1 (fr) Procédé de contrôle de l&#39;obtention par un terminal d&#39;un fichier de configuration

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

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

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

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

Free format text: ORIGINAL CODE: 0009012

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

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20190718

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: ORANGE

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

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20200805

RAP3 Party data changed (applicant data changed or rights of an application transferred)

Owner name: ORANGE