GB2590954A - Provision of digital content via a communication network - Google Patents

Provision of digital content via a communication network Download PDF

Info

Publication number
GB2590954A
GB2590954A GB2000294.5A GB202000294A GB2590954A GB 2590954 A GB2590954 A GB 2590954A GB 202000294 A GB202000294 A GB 202000294A GB 2590954 A GB2590954 A GB 2590954A
Authority
GB
United Kingdom
Prior art keywords
cryptographic
key
digital content
content
encryption key
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.)
Granted
Application number
GB2000294.5A
Other versions
GB202000294D0 (en
GB2590954B (en
Inventor
Willis Peter
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.)
British Telecommunications PLC
Original Assignee
British Telecommunications PLC
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 British Telecommunications PLC filed Critical British Telecommunications PLC
Priority to GB2000294.5A priority Critical patent/GB2590954B/en
Publication of GB202000294D0 publication Critical patent/GB202000294D0/en
Publication of GB2590954A publication Critical patent/GB2590954A/en
Application granted granted Critical
Publication of GB2590954B publication Critical patent/GB2590954B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0442—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0471—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload applying encryption by an intermediary, e.g. receiving clear information at the intermediary and encrypting the received information at the intermediary before forwarding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0478—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload applying multiple layers of encryption, e.g. nested tunnels or encrypting the content with a first key and then with at least a second key
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/008—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols involving homomorphic encryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/76—Proxy, i.e. using intermediary entity to perform cryptographic operations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0464—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload using hop-by-hop encryption, i.e. wherein an intermediate entity decrypts the information and re-encrypts it before forwarding it

Abstract

A method is disclosed for enabling digital content from a content provider, such as a Content Delivery Network (CDN) operator 14, to be provided from intermediate digital content stores, which may be CDN caches 16, to a user device 18. The provider provides content, encrypted with a public encryption key of a key-pair s20, to an intermediate content store s22. When the user device requests the content, the provider and user device share s23 a session key sk_u, possibly as part of a Transport Layer Security (TLS) handshake. The provider then generates s24 a re-encryption key sk_tx in dependence on a decryption key and the private key associated with the public encryption key, possibly using a cryptographic convolution and a homomorphic function, such that content encrypted with key pk_o and then re-encrypted using sk_tx can be decrypted using the decryption key. The provider provides sk_tx and indications of the requested content to the intermediate store s25, which enables the intermediate store to re-encrypt the content s26 and pass it on to the user device s27. The decryption key, with which the user device may decrypt the content s28, is the session key sk_u, thus avoiding another key exchange process.

Description

Intellectual Property Office Application No. GII2000294.5 RTM Date:22 June 2020 The following terms are registered trade marks and should be read as such wherever they occur in this document: I ET F Intel ARM TrustZone Intellectual Property Office is an operating name of the Patent Office www.gov.uk/ipo Provision of Digital Content via a Communication Network
Technical Field
The present invention relates to the provision of digital content via a communication network. In particular, aspects of the present invention relate to methods and apparatus for enabling digital content such as web-page content, television and other such media content from a content provider to be provided via a communication network from intermediate digital content stores to user-devices.
Background
Various background technologies and techniques will first be discussed.
Content Delivery Networks (CDNs) and CDN caches A Content Delivery Network (CDN) is a system of digital content-providing servers (or more generally, computers) generally operating under common control, the servers/computers each containing copies of items of data such as web-page content, television and other such media content, etc. that one or more Content Provider organisations may wish to be able to provide (on request) to their existing or potential clients. The CDN computers or nodes are placed at various points in a data network so as to allow clients to access and obtain data content they require from a computer/node nearby (in the network), rather than all clients needing to access a single central server of the Content Provider organisation in question.
Content Delivery Networks (CDNs) are increasingly being used by Content Provider organisations wishing to distribute their digital content to customers' devices or client devices (sometimes referred to as "eyeballs"). The client devices can be as simple as web browsers, or may involve applications such as Internet Protocol television (IPTV) client devices and set-top boxes (STBs).
The Content Provider organisation is motivated in several ways. Firstly, using a CDN removes or reduces the requirement to host content on its own servers and ensure that these servers can offer the capacity required by numerous customers. Secondly the Content Provider reduces the capacity it requires from network service providers to connect its servers. Lastly the CDN can provide better service to the customers to experience the content. In this regard the CDN provides multiple content hosting sites (known as "surrogates") nearer (topologically and/or geographically) in the network to their customers. It does this by maintaining a large number of distributed surrogates, and selecting the one that will provide the best performance On terms of network location and/or load on the server).
Virtual CDN A network operator may have a small number of CDN operators (possibly ten or more, depending on the size of the network operator and/or its network, and/or the geographical size of the region in which it operates), each with their caches, or surrogates, located at several core network sites. At peak times, a significant proportion (e.g. 50%) of a network operator's broadband traffic may be sourced from these caches. If these caches could be moved closer to the edge of the network operator's network (i.e. nearer to the respective Content Providers' customers, who are generally the end-consumers of the content in question), network traffic would be reduced sufficiently to allow the network operator to make significant cost-savings. However it is unlikely that these CDN operators would wish to have to install their caches at a (possibly very) large number of "edge" sites in the network operator's network (possibly over a thousand sites), due to the large investment required, and even if they were willing to do so, some network operators may not be able to accommodate, power, cool and otherwise maintain all of the various CDN operators' (possibly separate) racks of equipment in each of those sites. The Virtual CDN (''vCDN'') concept is one where the network operator in question provides the infrastructure at the edge sites, mainly computers and computer storage, which the CDN operators can use to host their own software and content. The vCDN service could be described as an "Infrastructure as a Service" ("laaS") offering tailored for CDN operators and the network operator's edge sites. The significant issue for CDN operators not using their own hardware is one of trusting the laaS provider (i.e. the network operator), especially with any cryptographic keys that have to be stored on the network operator's hardware to enable secure connectivity and control of content distribution to end-users.
Transport Laver Security (TLS) Private Keys Transport Layer Security (TLS) is a cryptographic protocol to provide communications security over a computer network and is the protocol behind Hypertext Transfer Protocol Secure (HTTPS) that is used to give web browsers secure access to web content. TLS provides privacy, data integrity and authentication so that a customer or other such user can be assured that their client device has connected to the right web page and that the content has not been tampered with "in-flight". Further, any confidential information (such as credit card details) entered/sent by the user is secure. The content provider may additionally authenticate the end-user and/or user's client device to ensure they are authorised to receive the content.
TLS uses a handshake with an asymmetric cipher to establish cipher settings and a session-specific shared key with which further communication is encrypted using a symmetric cipher. The server usually then provides identification in the form of a digital certificate. The certificate contains the server name, the trusted Certificate Authority (CA) that vouches for the authenticity of the certificate, and the server's public encryption key. The client device confirms the validity of the certificate before proceeding. The client device may then proceed in one of the following ways, for example: - encrypt a random number with the server's public key and send the result to the server (which only the server should be able to decrypt with its private key). Both parties then use the random number to generate a unique session key for subsequent encryption and decryption of data during the session; or - use Diffie-Hellman key exchange to securely generate a random and unique session key for encryption and decryption.
For a CDN, TLS requires that the private keys associated with the Content Providers, are stored on the hosting site/cache/surrogate.
Proxy Re-Encryption (PRE) Proxy re-encryption (PRE) schemes are cryptosystems which allow third parties (proxies) to alter a "ciphertext" which has been encrypted for one party, so that it may be decrypted by another. A "ciphertext" is the result of performing an encryption process, usually on plain (i.e. unencrypted) text, but it may be the result of performing a second or further encryption process on an already-encrypted ciphertext. PRE has many implementations and is the subject of much current research. A survey of PRE schemes entitled "Proxy Re-encryption Schemes for Secure Cloud Data and Applications: A Survey" is available online here: httos:fincifs.sernantitscholar. orai5b1 218db3fedie78f67dgccdflae6c7bd8ecef6a.odi Homomorphic Encryption Homomorphic encryption is a form of encryption that allows computation on ciphertexts, generating an encrypted result which, when decrypted, matches the result of the operations as if they had been performed on the plaintext. It is used for Threshold-Based PRE, for example.
Referring to prior disclosures, a paper entitled "Improved Proxy Re-Encryption Schemes with Applications to Secure Distributed Storage" by Giuseppe Ateniese, Kevin Fu, Matthew Green & Susan Hohenberger, 1 Feb 2006, available at: http://soarisilhumdui-mgreeniproxy.pdf, discusses an atomic proxy re-encryption application proposed in 1998 by Blaze, Bleumer and Strauss (BBS), in which a semi-trusted proxy converts a ciphertext for "Alice" (A) into a ciphertext for "Bob" (B) without seeing the underlying plaintext. Ateniese et al predicted that fast and secure re-encryption would become increasingly popular as a method for managing encrypted file systems, but noted that although efficiently computable, the wide-spread adoption of BBS re-encryption had been hindered by considerable security risks. They presented re-encryption schemes that aimed to realise a stronger notion of security and to show the usefulness of proxy re-encryption as a method of adding access control to the "Storage File System" (SFS) read-only system.
The 1998 proposal referred to is set out in ''BBS Proxy Re-Encryption" (Blaze, M, Bleumer, G, & Strauss, M (1998), Divertible Protocols and Atomic Proxy Cryptography, published in: Advances in Cryptology -EUROCRYPT '98 (pages 127-144), Springer Berlin Heidelberg, available online from: Ottp.:filinKs:prinagr.c.piaich_aptcrli 01 007/B................
A paper entitled "Homomorphic Encryption Scheme Based on Elliptic Curve Cryptography for Privacy Protection of Cloud Computing" by Ming-Quan Hong, Peng-Yu Wang & Wen-Bo Zhao, 9 April 2016, available online at: httpsilieeexplorelee-e.omidocurnent/7502281 discusses how "Cloud computing" is becoming a primary computing model, but notes that it is important for storage and transmission to be secured against possible attacks such as known-plain-text attack, and that ensuring data security and preserving privacy has hindered development. The paper notes that the Secure Multiparty Computation (SMC) problem has been solved using Trusted Third Party (TTP) techniques, but that use of TTPs themselves can be problematic. To protect user's privacy, encrypted outsourcing data are generally stored and processed in cloud computing by applying homomorphic encryption. The paper proposes use of an Elliptic Curve Cryptography (ECC) based homomorphic encryption scheme.
Summary of the Invention
As indicated earlier, a significant proportion of the broadband traffic carried by a large network operator's network may originate from content caches installed and operated by Content Delivery Network ("CDN") operators in the core of the network operator's network. If the network operator could move these CDN caches from the core to the edge of their network, the network operator would be able to make considerable cost-savings, but a large network operator may have several CDN operators in its core who may not be willing to install their own hardware at the (generally) very large number of edge locations around the network operator's network. Further, even if they were willing to make this investment, necessary or desired resources such as space and power to accommodate their equipment may not be available at those thousand or more edge locations. A solution to that could be for the network operator to install a common infrastructure and operate it as an "Infrastructure as a Service" that the CDN operators can use, on which to install their CDN caches. In relation to this solution, however, some CDN operators have raised concerns with trusting the network operators' infrastructure to host the private keys that may need to be used to authenticate their content. A public-private key pair may be used to establish a secure connection to a (Content Provider's or CDN operator's) client's browser, and it is the public key that the browser may use to authenticate the received content as genuine. The security risk to a CDN operator of "losing' the private keys could be significant, however -a malicious third party could then do significant damage to a Content Provider's reputation and cause other significant problems by generating "fake news" sites that look real and appear to come from a known Content Provider, for example.
According to a first aspect of the invention, there is provided a method for enabling digital content from a content provider to be provided via a communication network from intermediate digital content stores to user-devices, the method comprising: the content provider providing digital content encrypted using a cryptographic encryption key to an intermediate digital content store, the cryptographic encryption key being a public key of a key-pair and having an associated private key; and in response to a request from a user-device to the content provider for said digital content: - sharing a cryptographic session key between the content provider and the requesting user-device via the communication network, the cryptographic session key enabling encryption and decryption of data exchanged during a communication session between the content provider and the requesting user-device via the communication network; - the content provider generating a cryptographic re-encryption key in dependence on a cryptographic decryption key and on the private key associated with the cryptographic encryption key such that content encrypted using the cryptographic encryption key then re-encrypted using the cryptographic re-encryption key may be decrypted using the cryptographic decryption key; and - the content provider providing to the intermediate digital content store the cryptographic re-encryption key and indications of the requested digital content and of the user-device in respect of which the digital content has been requested, whereby to enable the encrypted digital content provided to the intermediate digital content store to be re-encrypted after receipt at the intermediate digital content store using the cryptographic re-encryption key, and whereby to enable the re-encrypted digital content to be provided by the intermediate digital content store to the requesting user-device via the communication network; characterised in that the cryptographic decryption key in dependence on which the cryptographic re-encryption key is generated is the cryptographic session key that has been shared between the content provider and the requesting user-device.
Preferably the cryptographic session key is a private key shared only between the content provider and the requesting user-device, and/or is not shared with the intermediate digital content store or with an entity controlling that.
In preferred embodiments, the intermediate digital content store is located at an edge of the communication network, at a location relatively near to the user-device and/or at a location in the communication network remote from the network core.
According to preferred embodiments, the content provider provides encrypted digital content items to the intermediate digital content store prior to receiving requests from user-devices for said digital content items.
According to preferred embodiments, the content provider provides a particular encrypted digital content item to the intermediate digital content store in response to receiving a request from a user-device for said particular digital content item.
According to preferred embodiments, the step of sharing the cryptographic session key between the content provider and the requesting user-device is performed in response to receipt by the content provider of a request from the user-device according to a current version of a Transport Layer Security protocol.
According to preferred embodiments, the step of sharing the cryptographic session key between the content provider and the requesting user-device comprises negotiating the cryptographic session key according to a current version of a Transport Layer Security protocol.
According to preferred embodiments, the step of generating the cryptographic re-encryption key comprises generating the cryptographic re-encryption key using a cryptographic convolution of the cryptographic decryption key and the private key associated with the cryptographic encryption key.
According to preferred embodiments, the step of generating the cryptographic re-encryption key comprises generating the cryptographic re-encryption key using a homomorphic encryption function. The encryption function may use or symmetric asymmetric encryption.
According to preferred embodiments, the method enables digital content from the content provider to be provided via the communication network from one or more of a plurality of intermediate digital content stores to one or more of a plurality of user-devices.
According to a second aspect of the invention, there is provided apparatus for enabling digital content from a content provider to be provided via a communication network from intermediate digital content stores to user-devices, the apparatus comprising a content provider and an intermediate digital content store, wherein: the content provider is configured to provide digital content encrypted using a cryptographic encryption key to the intermediate digital content store, the cryptographic encryption key being a public key of a key-pair and having an associated private key; the content provider further being configured to perform the following in response to a request from a user-device to the content provider for said digital content: -share a cryptographic session key between itself and the requesting user-device via the communication network, the cryptographic session key enabling encryption and decryption of data exchanged during a communication session between the content provider and the requesting user-device via the communication network; -generate a cryptographic re-encryption key in dependence on a cryptographic decryption key and on the private key associated with the cryptographic encryption key such that content encrypted using the cryptographic encryption key then re-encrypted using the cryptographic re-encryption key may be decrypted using the cryptographic decryption key; and -provide to the intermediate digital content store the cryptographic re-encryption key and indications of the requested digital content and of the user-device in respect of which the digital content has been requested, whereby to enable the encrypted digital content provided to the intermediate digital content store to be re-encrypted after receipt at the intermediate digital content store using the cryptographic re-encryption key, and whereby to enable the re-encrypted digital content to be provided by the intermediate digital content store to the requesting user-device via the communication network; characterised in that the cryptographic decryption key in dependence on which the cryptographic re-encryption key is generated is the cryptographic session key that has been shared between the content provider and the requesting user-device.
The various options and preferred embodiments referred to above in relation to the first aspect are also applicable in relation to the second aspect.
Preferred embodiments use proxy re-encryption with homomorphic encryption techniques to protect and authenticate a CDN operator's content when stored in caches within a network operator's infrastructure, without requiring the CDN operator to disclose their private keys to the network operator. It may be regarded as a two-step process in which the CDN operator encrypts the content with a private key which may be known only to them before sending that content to the network operator's infrastructure. When a customer connects, the CDN operator passes a session key to the customer and another key to the network operator to use to "re-encrypt" the already-encrypted content (without decrypting it) which can then only be read using the session key which is sent directly to the customer by the CDN operator (generally as part of the session initiation procedure between the CDN operator and the customer), and does not therefore need to be provided to (or even via) the network operator. It is therefore not possible for the network operator to modify the content, nor is it possible for the content to be intercepted and changed "in-flight" between the CDN operator and the customer.
The use of proxy re-encryption and homomorphic encryption for securely sharing files in cloud computing is well-documented but the use of such proxy re-encryption is not known to have been extended to CDN scenarios. Further, "re-using" a session key (which is shared anyway between the customer and the CDN operator as part of their session initiation procedure) as the "decryption key" to be used by the customer to decrypt the "encrypted then re-encrypted" content allows the technique to make use of known, standardised session-establishment procedures (e.g. the HTTPS TLS handshake procedure discussed below) to share the key that will subsequently be used as the decryption key, so avoids the need for further secure communication between the customer and the CDN operator, or for further software to be installed on the customer's device for such secure communication, while also allowing the customer and the CDN operator to authenticate each other's identities by virtue of the session key if necessary. (RTM1
Two similar protocol solutions being developed in ETSI and the IETF may be used in relation to the issue of CDNs and private keys operating on third party infrastructure, as follows: - IETF LURK: https:1 ailarchivelefflorclarch/rnscillurkiVXERS6Yr1UXwqSYO5mTnukz8DBk./4 - mcTLS -Modification to TLS to make it multi-party i.e. permit middleboxes: mcTLS (i.e. Multi-context TLS) is now known as TLMSP (Transport Layer Middlebox Security Protocol) as standardised in ETSI-TC-CYBER group, see: https://docbox.etsi.orgANorkshool2018/201806 ETSISECURITYWEEK/MIDDLEBOX/S03 JOI NT EFFORTS/ETSI TO CYBER MSP/ETSI TO CYBER MSP Introduction eTLS CIS RU TKOWSKI.odf These solutions do not encrypt the data at rest on the network operator's infrastructure (cache) and there is a degree of trust between the CDN operator and the infrastructure operator that still assumes the certificates are safely stored and used on the infrastructure. For example it would be possible for either the content to be manipulated or for the certificates to be changed in order to pass potentially-misleading content off as genuine by associating it with an apparently trustworthy certificate or content-provider (e.g. "fake news").
Another approach to solve the above problem of storing private keys may involve using secure memory enclaves. Both Intel (with "Software Guard Extensions" or SGX, which is a set of RTM) (F7Thq security-related instruction codes that can be built into some Intel CPUs) and ARM (with (RTM) "TrustZone", which is a security approach with hardware-enforced isolation to establish secure end points and a device root of trust) are developing technology that allows a tenant (which, in the case of embodiments of the present invention, would generally be a CDN operator) to declare a piece of memory on the server an enclave that is only readable by them (or more accurately their application). An enclave cannot be read by the infrastructure owner or administrator nor any other tenant using that server. This may protect the private keys at rest on the server. However CDN operators have raised the issue of trusting the enclave implementation, on the grounds that they may not know if the network operator's server has in fact been compromised but the enclaves have been hacked and altered to look like they are working and appear uncompromised. The technology required to do this is called "Attestation" where the CDN operator could attest that the code and hardware that the network operator is using to implement enclaves has not been tampered with. However even the attestation code has to be trusted and could have been tampered with. Attestation and enclaves are thus only a partial solution dependent on the CDN operators trusting the network operator's implementation.
Some homomorphic encryption techniques currently use asymmetric encryption techniques (e.g. elliptical encryption), which require relatively high CPU power, and the cipher text is significantly larger than the clear text for symmetric encryption techniques used by standard TLS today. However either future homomorphic encryption techniques, essentially new mathematical algorithms or future hardware improvements may make homomorphic encryption techniques for proxy-re-encryption less power-intensive.
Brief Description of the Drawings
A preferred embodiment of the present invention will now be described with reference to the appended drawings, in which: Figure 1 shows the primary entities involved in an embodiment of the invention; Figure 2 illustrates a process for implementing an embodiment of the invention; and Figure 3 is a block diagram of a computer system suitable for the operation of embodiments of the present invention.
Description of Preferred Embodiments of the Invention With reference to the accompanying figures, methods, apparatus and systems according to preferred embodiments will be described.
Referring to Figure 1, this shows the primary entities involved in the present embodiment.
These are as follows: - One or more CDN operators 14 from which end-users will request content; - One or more CDN caches 16 usually located in a network operator's network 10; and - A number of end-users 18 requesting the digital content (i.e. data, generally in an encrypted form) from the CDN operators 14.
It will be noted that the content which end-users 18 may request from CDN operators 14 need not and usually will not originate from the CDN operators themselves (although it may do). There would generally be one or more "original" content providers 12 who may supply content to the CDN operators 14, but the manner in which this interaction is performed is not of particular importance to the present description as this may be performed using known techniques, so for the purposes of the present description, the CDN operators 14 will generally be regarded as the actual Content Providers since they are generally more "directly" performing the role of Content Provision in relation to the interactions to be described.
There would generally be a many-to-many relationship between all these entities, e.g. each CDN operator 14 will generally use multiple caches 16 (possibly in multiple network operators' networks 10), with multiple end-users 18, and each end-user 18 can request data from multiple CDN operators, but the present embodiment will be described primarily with reference to one CDN operator 14 acting in a role as the (direct) Content Provider in order to provide content via one CDN cache 16 to an end-user 18 who has requested that content. It is generally immaterial in the present context whether the content in question to be provided by the CDN operator 14 in question via the CDN cache 16 in question to the end-user 18 in question has in fact previously been supplied to the CDN operator 14 by an "original" content provider 12 or not, or whether the user's initial request for the content in question was conveyed directly to the "original" content provider 12 or to the CDN operator 14 acting in its role as the (direct) Content Provider.
Figure 2 illustrates a process for implementing the present embodiment. For simplicity of illustration the process shows that the encrypted content is pushed by the CDN operator to the CDN cache but the present technique is also applicable in respect of embodiments in which when an End-User 14 requests content that has not been pre-cached, this causes the CDN cache 16 to request that content from the CDN Operator 14, the CDN Operator 14 then encrypting the content in question "on-the-fly" before sending it to the CDN cache 16.
The process according to the present embodiment is as follows (on the basis that the content in question has already been supplied in this case (at a preliminary step s19) by an "original" content provider 12 to the CDN operator 14): 1. In step s20, the CDN Operator 14 encrypts the content with a "public" key pk o. (NB The CDN Operator would generally keep this "public" key secret as it prevents third parties from generating fake content. This key is only called "public" in this instance because it is intended for asymmetric key encryption which uses public-private pairs of keys. In this case the same key generation algorithms are used to generate a private-private pair of asymmetric keys, comprising the operator's "public' key pk o and its associated private key sk o.) 2. In step s21, the CDN Operator 14 sends the encrypted content to the CDN cache 16. The content will be stored with a unique content identifier "content_id", 3. In step s22, the CDN cache 16 stores the encrypted content with content_id.
4. In step s23, the End-User 18 makes an HTTP request to the CDN Operator 14 (noting that the request could in some embodiments be made to the "original" content provider 12) using the TLS protocol. A TLS shared private key sk u is negotiated for the user to use.
5. In step s24, the CDN Operator 14 generates a third secret key sk tx from a cryptographic convolution of the operator's and user's shared private key sk u and the operator's private key sk o. (As above, this step could in some embodiments be performed instead by the "original" content provider 12.) 6. In step s25, the CDN Operator 14 sends third secret key sk_tx to the CDN cache 16 together with instructions to send the content with the applicable content id to the end-user 18 in question.
7. In step s26, the CDN cache 16 re-encrypts the already once-encrypted content with the third secret key sk tx.
8. In step s27, the CDN cache 16 sends the re-encrypted content to the End-User 18.
9. In step s28, the End-User 18 decrypts the content using the shared private key sk u negotiated with the CDN Operator 14 in step s23 (as described in Stage 4 above).
The End-User 18 is now able to access, and if appropriate, play the content.
[NB In the above example, the operation performed in step s24 (Stage 5 as set out above) in order to generate the third secret key ''sk tx" is a cryptographic convolution of the CDN operator's and the user's shared private key sk_u and the CDN operator's own private key sk_o, which is an example of a "homomorphic" encryption function as discussed earlier, but it will be appreciated that the operation to generate the third secret key "sk tx" may involve other functions of the CDN operator's and user's shared private key sk u and the CDN operator's private key sk o].
In this embodiment, the shared private key sk u (i.e. the key shared between the CDN operator and the user) is the key shared anyway between the CDN operator (or original content provider) and the user for the purposes of the TLS handshake or other such (direct or indirect) communication between the CDN operator (or original content provider) and the user. It will be noted that this would not generally be shared with the network operator or other such intermediate entity responsible for operating the CDN cache 16. The shared private key sk_u need not be the TLS shared private key itself, but is preferably a key that would be shared anyway between the CDN operator and the user for reasons other than the generation of the third secret key sk tx. This not only makes efficient use of computing and communication resources but avoids the need to set up an additional exchange process.
Preferred embodiments may be implemented using a variety of cryptographic algorithms, preferably homomorphic encryption algorithms such as (for example) the Elliptic Curve Cryptography algorithms from the 1998 BBS paper discussed earlier (i.e. "BBS Proxy Re-Encryption" by Blaze, Bleumer and Strauss), but other encryption algorithms may be used.
Code such as that shown below may be used in relation to implementations such as the presently-described embodiment: #.1/usr/bin/env python3 from npre import bbs98 pre = bbs98.PREO sk o = pre.gen_priv(dtype-bytes) #CDN Operators private key pk o = prapriv2pub(sk o) #CDN Operators public key -although can be kept secret sk u = pre.gen_priv(dtype=bytes) #Session private key shared between CDN operator and user pk u = pre.priv2pub(sk u) if User public key not used here print ("CDN operators private key=';sk o,"In") print ("CDN operators Inpublicl" key but should be kept private so no one can generate fake content=",pk o,"In") print ("CDN operator and end-users shared secret key=",sk u,"In") print ("End-users public key (not used)=",pk msg=b'Hello World' print ("Original Content",msg.decode('utf-8),"In"); cache = pre.encrypt(pk o, msg) #CDN operator encodes with secret public key print ("Cached content",cache,"In"); txkey = pre.rekey(sk o,sk u)#CDN operator calculates transmission key for cache to send data to end-user. Note normal TLS uses a shared symmetric key so this is just as secure. CDN operator passes this txkey to the cache along with details of content to play to end-user.
txmsg = pre.reencrypt(txkey, cache) #Message cache sends to user print ("Txmsg",txmsg,"In"); finalmsg=pre.decrypt (sk u, txmsg) #End-user decodes with private key shared with CDN operator print ("Decoded content=",finalmsg.decode('uff-89,"In") Figure 3 is a block diagram of a computer system suitable for the operation of embodiments of the present invention. A central processor unit (CPU) 302 is communicatively connected to a data store 304 and an input/output (I/O) interface 306 via a data bus 308. The data store 304 can be any read/write storage device or combination of devices such as a random access memory (RAM) or a non-volatile storage device, and can be used for storing executable and/or non-executable data. Examples of non-volatile storage devices include disk or tape storage devices. The I/O interface 306 is an interface to devices for the input or output of data, or for both input and output of data. Examples of I/O devices connectable to I/O interface 306 include a keyboard, a mouse, a display (such as a monitor) and a network connection.
Insofar as embodiments of the invention described are implementable, at least in part, using a software-controlled programmable processing device, such as a microprocessor, digital signal processor or other processing device, data processing apparatus or system, it will be appreciated that a computer program for configuring a programmable device, apparatus or system to implement the foregoing described methods is envisaged as an aspect of the present invention. The computer program may be embodied as source code or undergo compilation for implementation on a processing device, apparatus or system or may be embodied as object code, for example.
Suitably, the computer program is stored on a carrier medium in machine or device readable form, for example in solid-state memory, magnetic memory such as disk or tape, optically or magneto-optically readable memory such as compact disk or digital versatile disk etc., and the processing device utilises the program or a part thereof to configure it for operation. The computer program may be supplied from a remote source embodied in a communications medium such as an electronic signal, radio frequency carrier wave or optical carrier wave. Such carrier media are also envisaged as aspects of the present invention.
It will be understood by those skilled in the art that, although the present invention has been described in relation to the above described example embodiments, the invention is not limited thereto and that there are many possible variations and modifications which fall within the scope of the invention.
The scope of the invention may include other novel features or combinations of features disclosed herein. The applicant hereby gives notice that new claims may be formulated to such features or combinations of features during prosecution of this application or of any such further applications derived therefrom. In particular, with reference to the appended claims, features from dependent claims may be combined with those of the independent claims and features from respective independent claims may be combined in any appropriate manner and not merely in the specific combinations enumerated in the claims.

Claims (10)

  1. Claims 1) A method for enabling digital content from a content provider to be provided via a communication network from intermediate digital content stores to user-devices, the method comprising: the content provider providing digital content encrypted using a cryptographic encryption key to an intermediate digital content store, the cryptographic encryption key being a public key of a key-pair and having an associated private key; and in response to a request from a user-device to the content provider for said digital content: -sharing a cryptographic session key between the content provider and the requesting user-device via the communication network, the cryptographic session key enabling encryption and decryption of data exchanged during a communication session between the content provider and the requesting user-device via the communication network; -the content provider generating a cryptographic re-encryption key in dependence on a cryptographic decryption key and on the private key associated with the cryptographic encryption key such that content encrypted using the cryptographic encryption key then re-encrypted using the cryptographic re-encryption key may be decrypted using the cryptographic decryption key; and -the content provider providing to the intermediate digital content store the cryptographic re-encryption key and indications of the requested digital content and of the user-device in respect of which the digital content has been requested, whereby to enable the encrypted digital content provided to the intermediate digital content store to be re-encrypted after receipt at the intermediate digital content store using the cryptographic re-encryption key, and whereby to enable the re-encrypted digital content to be provided by the intermediate digital content store to the requesting user-device via the communication network; characterised in that the cryptographic decryption key in dependence on which the cryptographic re-encryption key is generated is the cryptographic session key that has been shared between the content provider and the requesting user-device.
  2. 2) A method according to Claim 1 wherein the content provider provides encrypted digital content items to the intermediate digital content store prior to receiving requests from user-devices for said digital content items.
  3. 3) A method according to Claim 1 or 2 wherein the content provider provides a particular encrypted digital content item to the intermediate digital content store in response to receiving a request from a user-device for said particular digital content item.
  4. 4) A method according to Claim 1, 2 or 3 wherein the step of sharing the cryptographic session key between the content provider and the requesting user-device is performed in response to receipt by the content provider of a request from the user-device according to a current version of a Transport Layer Security protocol.
  5. 5) A method according to any of the preceding claims wherein the step of sharing the cryptographic session key between the content provider and the requesting user-device comprises negotiating the cryptographic session key according to a current version of a Transport Layer Security protocol.
  6. 6) A method according to any of the preceding claims wherein the step of generating the cryptographic re-encryption key comprises generating the cryptographic re-encryption key using a cryptographic convolution of the cryptographic decryption key and the private key associated with the cryptographic encryption key.
  7. 7) A method according to any of the preceding claims wherein the step of generating the cryptographic re-encryption key comprises generating the cryptographic re-encryption key using a homomorphic encryption function.
  8. 8) A method according to any of the preceding claims, the method enabling digital content from the content provider to be provided via the communication network from one or more of a plurality of intermediate digital content stores to one or more of a plurality of user-devices.
  9. 9) Apparatus for enabling digital content from a content provider to be provided via a communication network from intermediate digital content stores to user-devices, the apparatus comprising a content provider and an intermediate digital content store, wherein: the content provider is configured to provide digital content encrypted using a cryptographic encryption key to the intermediate digital content store, the cryptographic encryption key being a public key of a key-pair and having an associated private key; the content provider further being configured to perform the following in response to a request from a user-device to the content provider for said digital content: -share a cryptographic session key between itself and the requesting user-device via the communication network, the cryptographic session key enabling encryption and decryption of data exchanged during a communication session between the content provider and the requesting user-device via the communication network; -generate a cryptographic re-encryption key in dependence on a cryptographic decryption key and on the private key associated with the cryptographic encryption key such that content encrypted using the cryptographic encryption key then re-encrypted using the cryptographic re-encryption key may be decrypted using the cryptographic decryption key; and -provide to the intermediate digital content store the cryptographic re-encryption key and indications of the requested digital content and of the user-device in respect of which the digital content has been requested, whereby to enable the encrypted digital content provided to the intermediate digital content store to be re-encrypted after receipt at the intermediate digital content store using the cryptographic re-encryption key, and whereby to enable the re-encrypted digital content to be provided by the intermediate digital content store to the requesting user-device via the communication network; characterised in that the cryptographic decryption key in dependence on which the cryptographic re-encryption key is generated is the cryptographic session key that has been shared between the content provider and the requesting user-device.
  10. 10) A computer program element comprising computer program code to, when loaded into a computer system and executed thereon, cause the computer to perform the steps of a method as claimed in any of claims 1 to 8.
GB2000294.5A 2020-01-09 2020-01-09 Provision of digital content via a communication network Active GB2590954B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
GB2000294.5A GB2590954B (en) 2020-01-09 2020-01-09 Provision of digital content via a communication network

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
GB2000294.5A GB2590954B (en) 2020-01-09 2020-01-09 Provision of digital content via a communication network

Publications (3)

Publication Number Publication Date
GB202000294D0 GB202000294D0 (en) 2020-02-26
GB2590954A true GB2590954A (en) 2021-07-14
GB2590954B GB2590954B (en) 2022-07-06

Family

ID=69626277

Family Applications (1)

Application Number Title Priority Date Filing Date
GB2000294.5A Active GB2590954B (en) 2020-01-09 2020-01-09 Provision of digital content via a communication network

Country Status (1)

Country Link
GB (1) GB2590954B (en)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120317655A1 (en) * 2011-06-10 2012-12-13 Futurewei Technologies, Inc. Method for Flexible Data Protection with Dynamically Authorized Data Receivers in a Content Network or in Cloud Storage and Content Delivery Services
US20150270957A1 (en) * 2014-03-19 2015-09-24 Palo Alto Research Center Incorporated System and method for efficient and secure distribution of digital content
JP2019121999A (en) * 2018-01-11 2019-07-22 日本電信電話株式会社 Data sharing method, data sharing system, communication terminal, data sharing server, and program

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120317655A1 (en) * 2011-06-10 2012-12-13 Futurewei Technologies, Inc. Method for Flexible Data Protection with Dynamically Authorized Data Receivers in a Content Network or in Cloud Storage and Content Delivery Services
US20150270957A1 (en) * 2014-03-19 2015-09-24 Palo Alto Research Center Incorporated System and method for efficient and secure distribution of digital content
JP2019121999A (en) * 2018-01-11 2019-07-22 日本電信電話株式会社 Data sharing method, data sharing system, communication terminal, data sharing server, and program

Also Published As

Publication number Publication date
GB202000294D0 (en) 2020-02-26
GB2590954B (en) 2022-07-06

Similar Documents

Publication Publication Date Title
US11477037B2 (en) Providing forward secrecy in a terminating SSL/TLS connection proxy using ephemeral Diffie-Hellman key exchange
US20210385201A1 (en) Systems and methods for secure multi-party communications using aproxy
US11038854B2 (en) Terminating SSL connections without locally-accessible private keys
US11165565B2 (en) Secure distribution private keys for use by untrusted code
JP2021083076A (en) Data transmission method, apparatus and system
US9137017B2 (en) Key recovery mechanism
US9948674B2 (en) Splicing into an active TLS session without a certificate or private key
EP3170282B1 (en) Data distributing over network to user devices
JP2020532177A (en) Computer-implemented systems and methods for advanced data security, high-speed encryption, and transmission
JP2010004288A (en) Secret information transmission system, secret information transmission method, secret information management server, encryption device, secret information transmission program
CN110581829A (en) Communication method and device
CN115766066A (en) Data transmission method, device, safety communication system and storage medium
EP3216163B1 (en) Providing forward secrecy in a terminating ssl/tls connection proxy using ephemeral diffie-hellman key exchange
US20230041783A1 (en) Provision of digital content via a communication network
GB2590954A (en) Provision of digital content via a communication network
US20190379645A1 (en) System for secure arbitrary data transport
JP2018107625A (en) Data distribution system, data generation device, mediation device, data distribution method, and program
WO2016141513A1 (en) Service processing method and apparatus
Ahammad et al. Key based secured cryptosystems used for online data sharing on the cloud
CN114386054A (en) Control method, system and medium for message storage processing and security authentication