Ciphertext verification

Abstract

The present disclosure relates to a method of a data publisher device (10) distributing data content to receiving devices (11, 12) in a network and a method of a device (12) receiving data content in a network, and devices (10, 12) performing these methods. In one aspect, a method of a device (12) receiving data content in a network is provided. The method comprises receiving (S303, S307) encrypted data content from another device (11, 14) in the network, the data content having been encrypted with a symmetric key shared with a trusted data content publisher device (10), requesting (S304) from the trusted data content publisher device (10) a subset of the encrypted data content received from the other device (11) in the network, and verifying (S305) whether the subset of encrypted data content received from the trusted data content publisher device (10) matches a selected segment of the encrypted data content received from the other device (11, 14) in the network, wherein a match indicates that the encrypted data content received from the other device (11) can be trusted.

Description

Technical Field

[0001] This disclosure relates to a method by which a data publishing device distributes data content to a receiving device in a network, a method by which a device receives data content in a network, and a device for performing these methods. Background Technology

[0002] In many data distribution scenarios, verifying the received data is crucial. One such scenario is when data such as software installers, videos, audio, and text content is stored in an untrusted third-party location. This includes third-party caching or peer-to-peer (P2P) distribution, where data consumers trust the data publisher but not necessarily the intermediary data source.

[0003] A common solution is for the data publisher to digitally sign the content or provide a separate cryptographic hash, allowing end-user data consumers to securely verify the integrity of the publisher and / or the data they receive.

[0004] In the absence of means for data publishers to verify data content, end-user data consumers are vulnerable to a range of cyberattacks, from denial-of-service (DoS) attacks to attacks that give intruders full access to protected systems.

[0005] Changing the distribution chain or intermediate data sources of a data publisher is often complex due to technical or organizational reasons, so it is desirable to be able to verify the data content of the data publisher without changing any part of the distribution chain. Summary of the Invention

[0006] One goal is to address or at least mitigate this problem in the existing technology, and thus provide improved methods for distributing and downloading data content across networks.

[0007] This objective is achieved in a first aspect by a method of distributing data content to receiving devices in a network using a data publishing device. The method includes encrypting the data content with a secret encryption key shared with the receiving devices, distributing the encrypted data content to at least one of the receiving devices, and, upon request, sending a subset of the encrypted data content to at least another receiving device, which downloads the encrypted data content from one or more other receiving devices in the network.

[0008] This objective is achieved in a second aspect by a method for a device to receive data content in a network. The method includes receiving encrypted data content from another device in the network, the data content having been encrypted with a symmetric key shared with a trusted data content publisher device; requesting from the trusted data content publisher device a subset of the encrypted data content received from the other device (11) in the network; and verifying whether the subset of encrypted data content received from the trusted data content publisher device matches a selected segment of the encrypted data content received from the other device in the network, wherein a match indicates that the encrypted data content received from the other device can be trusted.

[0009] This objective is achieved in a third aspect by a data publishing device configured to distribute data content to receiving devices in a network, the data publishing device including a processing unit and a memory containing instructions executable by the processing. The data publishing device is operable to encrypt the data content with a secret encryption key shared with the receiving devices, distribute the encrypted data content to at least one of the receiving devices, and, upon request, send a subset of the encrypted data content to at least another receiving device, which downloads the encrypted data content from one or more other receiving devices in the network.

[0010] This objective is achieved in a fourth aspect of the invention by a device configured to receive data content in a network, the device including a processing unit and a memory containing instructions (212) executable by the processing unit. The device is operable to receive encrypted data content from another device in the network, the data content having been encrypted with a symmetric key shared with a trusted data content publisher device, requesting from the trusted data content publisher device a subset of the encrypted data content received from the other device in the network, and verifying whether the subset of encrypted data content received from the trusted data content publisher device matches a selected segment of the encrypted data content received from the other device in the network, wherein a match indicates that the encrypted data content received from the other device (11) is trustworthy.

[0011] Therefore, the data publisher distributes a segment of content, referred to as a stream or fragment, across the network, encrypted with a symmetric key shared by receiving client devices in a clustered manner within the network. The encrypted content is distributed, for example, to a first client device, which then distributes it to a second client device. The second client device can then use the shared key to decrypt and subsequently render the content, such as a video stream.

[0012] However, if a malicious device distributes malicious content that has already been encrypted with the same shared key to a second client, the second client device cannot distinguish whether the encrypted data content and the subsequently decrypted data content—called plaintext—or originated from a trusted device or a malicious device. Therefore, the malicious device can deceive the second client device because the shared key is used for encryption / decryption.

[0013] To overcome this problem, the second client device turns to the data publisher when receiving encrypted data content from the first client device and / or a malicious device, and issues a request to download a subset of the received encrypted content (which typically has an associated identifier that allows the second client device to signal to the data publisher which encrypted data content is being requested).

[0014] In the example, the encrypted data content could be 1GB in size, and the subset would only constitute 256 bits of that 1GB of encrypted content. The subset would constitute the last 256 bits of the total 1GB of encrypted data content. In other words, the subset constitutes a very small portion of the encrypted data content from which that subset is derived.

[0015] Therefore, the second client device compares a 256-bit subset with the last 256 bits of the received encrypted data content. If the two 256-bit subsets match, the data content is considered unmanipulated, the received encrypted data content is decrypted, and the plaintext data content is presented at the second client device. If the two 256-bit subsets do not match, the received encrypted data content is discarded.

[0016] Various embodiments of the present invention will be discussed below.

[0017] Generally, all terms used in the claims should be interpreted according to their ordinary meaning in the technical field, unless otherwise expressly defined herein. All references to “a / an / the element, device, component, means, step, etc.” should be interpreted as referring to at least one instance of an element, device, component, means, step, etc., unless otherwise expressly stated. The steps of any method disclosed herein need not be performed in the exact order disclosed, unless expressly stated. Attached Figure Description

[0018] Aspects and embodiments will now be described by way of example with reference to the accompanying drawings, in which:

[0019] Figure 1 Existing technical methods for distributing data content in a network are illustrated;

[0020] Figure 2 Demonstrates malicious devices that inject content into the network;

[0021] Figure 3Demonstrates the distribution of data content in a network according to an embodiment;

[0022] Figure 4 A flowchart illustrating a method for distributing data content on a network using a data publisher according to an embodiment is shown;

[0023] Figure 5 A flowchart illustrating a method for a device to receive data content in a network according to an embodiment is shown;

[0024] Figure 6 A flowchart illustrating a method for a device to receive data content in a network according to another embodiment is shown;

[0025] Figure 7 Demonstrating a data publishing device according to an embodiment; and

[0026] Figure 8 A client device according to an embodiment is shown. Detailed Implementation

[0027] Various aspects of this disclosure will now be described more fully below with reference to the accompanying drawings, in which certain embodiments are illustrated.

[0028] However, these aspects may be embodied in many different forms and should not be construed as limiting; rather, these embodiments are provided by way of example so that this disclosure will be thorough and complete, and will fully convey the scope of all aspects to those skilled in the art. Throughout the description, similar numbers refer to similar elements.

[0029] Figure 1 This demonstrates the problems in distributing data in P2P schemes in this field (even though this problem is also relevant to other types of distribution systems).

[0030] In step S101, a data publisher 10, in the form of a content delivery network (CDN), distributes data content to a first client device 11, such as a smartphone, laptop computer, tablet computer, etc., using, for example, Hypertext Transfer Protocol Security (HTTPS).

[0031] In this example, the data content is encrypted using a shared key, which may be provided to the first client device 11 and the second client device 12 by, for example, a Digital Rights Management (DRM) service 13. Any suitable encryption algorithm may be used, such as, for example, Advanced Encryption Standard (AES).

[0032] One advantage of a P2P system is that client devices 11 and 12 (typically referred to as peer devices in a P2P system) can share data content with each other. In other words, the first peer device 11 can share at least one fragment or stream of encrypted data content downloaded from the data publisher 10 with the second peer device 12 in step S102, while the second peer device 12 can download other fragments of data content from other peer devices (or from the source 10). The advantage of this method is that the second peer device 12 will not impose a burden on the data publisher 10 to download data content. Embodiments will be described with reference to P2P systems; however, embodiments can be applied to any suitable system for distributing data content from a source to a client.

[0033] Therefore, in step S101, the first peer device 11 downloads encrypted data content from the publisher 10, in step S103 it decrypts the encrypted data content using the shared key obtained from the DRM service 13, and in the case that the data content constitutes video data, it presents the content on the video player.

[0034] Correspondingly, in step S102, the second peer downloads all or a fragment of the encrypted data content shared by the first peer device 11, and in step S103, decrypts the encrypted data content using the same shared key obtained from the DRM service 13, and presents the content on the video player. It should be noted that peer devices 12 and 13 do not necessarily download the key from the DRM service 13, but may have already pre-configured the key.

[0035] exist Figure 2 If a malicious device 14 accesses the shared key distributed by the DRM service 13, then the malicious device 14 can encrypt malicious data (e.g., data intended to inject into the second peer device 12 and / or its users that causes inconvenience or even harm), and in step S201 distribute the encrypted malicious data to the second peer device 12 (or any other device using the shared key).

[0036] Therefore, malicious device 14 acts as an intermediate data source for injecting malicious data encrypted with the correct shared key. The second peer device 12 cannot verify the received encrypted fragments because the correct key has already been used for symmetric encryption.

[0037] Figure 3 The solutions to this problem, as provided by the embodiments, are illustrated. See also: Figure 4 and Figure 5 The flowcharts illustrate embodiments executed by the data publisher 10 and the second peer device 12, respectively.

[0038] Therefore, in the first step S301, as previously described, the data publisher 10 encrypts the data content to be distributed using a key shared with other peer devices 11, 12 in the network, and in step S302 distributes the encrypted data content to the first peer device 11. In practice, the network may include hundreds or even thousands of peer devices, and the publisher 10 typically performs direct distribution of the encrypted data content to multiple peer devices.

[0039] In step S303, the second peer device 12 downloads at least one fragment of the encrypted data content that the first peer device 11 downloaded from the data publisher 10 in step S302.

[0040] To allow the receiver of the encrypted data content to verify the correctness of the encrypted data content downloaded in step S303, the receiver—in this case, the second peer device 12—additionally downloads a small subset of the encrypted data content from the original data publisher 10 in step S304. In other words, the intended receiver in the distribution network that does not download data content directly from the data publisher 10 but from another peer device additionally downloads the small subset from the publisher 10.

[0041] It should be noted that since the first peer device 11 downloads data content directly from the data publisher 10 instead of from another peer device, the first peer device 11 does not need the subset to verify the correctness of the encrypted data content received in step S302. Typically, the first peer device 11 uses a certificate received from the publisher 10 to verify the data publisher 10, and therefore the first peer device 11 can authenticate the received encrypted data content by verifying the digital signature provided by the data publisher 10 to the encrypted data content.

[0042] As understood, fragments or streams distributed from the first peer device 11 (or malicious device 14) to the second peer device 12 typically have a size of gigabytes (GB), such as somewhere in the range of 2-20 GB.

[0043] In contrast, a subset of encrypted data fragments is typically around several hundred bits, such as, for example, 32 × 8 bits (i.e., 32 bytes). It should be noted that the second peer device 12 receiving the encrypted subset must trust the issuer of that encrypted subset, i.e., the data publisher 10. As previously mentioned, the data publisher 10 may have already distributed its certificate to peer devices on the network, thereby ensuring the authenticity of any data downloaded from the data publisher 10 by providing a digital signature to the data. In other words, the data publisher 10 can provide a trusted certificate that has already been signed by the root certificate.

[0044] The length of the encrypted data subset determines the security level; the larger the subset, the stronger the security, just like the length of the encryption key. In terms of security level, an encrypted data subset typically provides the same level of security as a hash function of corresponding length. Therefore, a 256-bit encrypted data subset will provide the same level of security as a 256-bit hash function such as SHA-256 (“Secure Hash Algorithm”), while a 512-bit encrypted data subset will provide the same level of security as SHA-512.

[0045] As mentioned above, the size of the encrypted data content to be presented by a peer device—from which an encrypted subset of data is derived—typically ranges from 1 to 20 GB, while the size of the derived subset is, for example, 128 to 512 bits (i.e., 16 to 64 bytes). Therefore, the relationship between the encrypted data content and the encrypted subset is typically at least 1 × 10⁻⁶. 9 / 64=15.625.000.

[0046] Assuming a relatively small segment of encrypted data content is downloaded, say 128 megabits, and the encrypted data subset derived from the segment has a length of 128 bits, the size of the subset is still only 1 ppm of the data content.

[0047] Therefore, a small subset of the encrypted data content distributed by data publisher 10 to the first peer device 11 (and additionally to the second peer device 12 in step S303) in step S302 is downloaded by the second peer device 12 from data publisher 10 in step S304. In other words, intended recipients in the distribution network that download data content from sources other than data publisher 10 will turn to the data publisher for downloading the encrypted data subset already derived from the downloaded encrypted data content.

[0048] Data publisher 10 is typically identified by a Uniform Resource Locator (URL) included in a so-called manifest file of peer devices initially distributed to the network. This URL identifies data publisher 10 and the data content fragments / streams distributed by data publisher 10. Therefore, after downloading a specific fragment in step S303, the second peer device 12 identifies the URL of data publisher 10 for the specific fragment in the manifest file (which may be set with an identifier to match the corresponding identifier in the manifest file), and downloads the encrypted subset of data in step S304.

[0049] Suppose, for example, a 1GB data segment is encrypted by the data publisher in step S301 and distributed to one or more peer devices in the network in step S302. Further assume that a 32-byte (256-bit) subset of the encrypted data is downloaded by a peer device from the data publisher 10, which in turn downloads the encrypted data from other peer devices. This 32-byte subset could be the first or last 32 bytes of the 1GB encrypted data, or any consecutive 32 bytes of the 1GB content. Hereinafter, the subset is exemplified as the last 32 bytes of the 1GB encrypted data. As understood, the second peer device 12 must know which part of the encrypted data segment this subset corresponds to; this could be information pre-configured on the second peer device 12.

[0050] After receiving encrypted data content from the first peer device 11 in step S303, the second peer device 11 will verify in step S305 whether the 32-byte subset downloaded in step S304 matches the last 32 bytes of the received encrypted data content. In this particular embodiment, the second peer device 12 compares the 32-byte subset received in step S304 with the last 32 bytes of the received encrypted data content. If the two 32-byte datasets are the same, then the second peer device 12 is assured that the received encrypted data content was indeed originally issued by the trusted data publisher 10 and has not been tampered with.

[0051] A 256-bit encrypted data subset can be used with AES-128, while a 512-bit encrypted subset can be used with AES-256. That is, when AES is used as a symmetric encryption scheme at the data publisher 10, the encrypted data subset downloaded from the data publisher 10 in step S304 can be selected to have twice the length of the shared symmetric key used for encryption / decryption.

[0052] The verification of the encrypted data content received in step S305 is therefore advantageously successful, and the encrypted data content can therefore optionally be decrypted using the shared key provided by DRM service 13, such as... Figure 5 The steps shown in step S306 are presented and are securely presented by the second peer device 12 on, for example, a video player.

[0053] Now, for reference Figure 3 and Figure 6If malicious device 14 provides encrypted malicious data to second peer device 12 in step S307, then second peer device 12 will download a subset of encrypted data from data publisher 10 in step S308, and in step S309 compare the last 32 bytes of the encrypted malicious data with the 32-byte subset of encrypted data received from data publisher 10, and determine that a mismatch exists. It is assumed here that malicious device 14 can correctly identify the encrypted malicious data so that second peer device 12 successfully (based on the identifier) ​​associates the malicious data with a URL segment identified in the manifest file as belonging to data publisher 10. If malicious device 14 provides encrypted malicious data to second peer device 12 that is not indicated as originating from data publisher 10 in the manifest file, then in step S308, the encrypted data subset will not be downloaded, and the encrypted malicious data will be discarded.

[0054] It should be noted that, in this field, if malicious device 14 is able to provide encrypted malicious data with an identifier that matches a data content fragment of the manifest file, then the second peer device 12 will continue to decrypt the encrypted malicious data because the received encrypted malicious data does indeed appear to originate from a trusted URL as specified in the manifest file. However, by providing step S308 of obtaining a subset from data publisher 10 and comparing the subset with selected segments of encrypted malicious data in step S309, such spoofing attempts are detected and successfully avoided.

[0055] In other words, since the 32-byte subset of encrypted data received from the publisher 10 in step S308 is different from the last 32 bytes of the encrypted malicious data received in step S307, the second peer device 12 will advantageously not verify the received malicious data in step S309, and therefore will not continue to decrypt the encrypted malicious data for subsequent execution (potentially with fatal consequences). Thus, the verification of the encrypted (malicious) data fails in step S309, which is the purpose of the encrypted subset provided by the data publisher 10.

[0056] For modern symmetric encryption algorithms like AES, plaintext and its encrypted copy (usually called ciphertext) have a relationship such that a single bit changed in the plaintext also has a 50% chance of changing in the ciphertext (i.e., a so-called bit avalanche occurs).

[0057] Therefore, it is computationally infeasible to create malicious plaintext to generate partially identical ciphertext under the same encryption key. In other words, it is computationally infeasible for malicious device 14 to encrypt plaintext to obtain ciphertext, where the 32-byte sequence of ciphertext would correspond to a subset of encrypted 32-byte data created by data publisher 10.

[0058] Typically, in this field, security issues are addressed by having the data publisher apply asymmetric signatures or use hashes, which would require corresponding actions at the peer device.

[0059] Figure 7 A data publishing device 10 according to an embodiment is shown, wherein the steps of the method actually performed by the data publishing device 10 are executed by a processing unit 111, which is embodied in the form of one or more microprocessors arranged to execute a computer program 112 downloaded to a storage medium 113 (such as random access memory (RAM), flash memory, or hard disk drive) associated with the microprocessors. The processing unit 111 is arranged to cause the data publishing device 10 to perform the method according to the embodiment when a suitable computer program 112, including computer-executable instructions, is downloaded to the storage medium 113 and executed by the processing unit 111. The storage medium 113 may also be a computer program product including the computer program 112. Alternatively, the computer program 112 may be transferred to the storage medium 113 via a suitable computer program product such as a digital multifunction disc (DVD) or memory stick. As another alternative, the computer program 112 may be downloaded to the storage medium 113 via a network. Alternatively, the processing unit 111 may be embodied in the form of a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a complex programmable logic device (CPLD), etc. The data publishing device 10 also includes a communication interface 114 (wired or wireless), through which the data publishing device 10 is configured to transmit and receive data.

[0060] Figure 8 A client device 12 according to an embodiment is shown, wherein the steps of the method actually performed by the client device 12 are executed by a processing unit 211, which is embodied in the form of one or more microprocessors arranged to execute a computer program 212 downloaded to a storage medium 213 (such as RAM, flash memory, or hard disk drive) associated with the microprocessors. The processing unit 211 is arranged to cause the client device 12 to perform the method according to the embodiment when a suitable computer program 212, including computer-executable instructions, is downloaded to the storage medium 213 and executed by the processing unit 211. The storage medium 213 may also be a computer program product including the computer program 212. Alternatively, the computer program 212 may be transferred to the storage medium 213 via a suitable computer program product such as a DVD or Memory Stick. As another alternative, the computer program 212 may be downloaded to the storage medium 213 via a network. Alternatively, the processing unit 211 may be embodied in the form of a DSP, ASIC, FPGA, CPLD, etc. The client device 12 also includes a communication interface 214 (wired or wireless), through which the client device 12 is configured to transmit and receive data.

[0061] The foregoing description of various aspects of this disclosure is primarily based on several embodiments and examples thereof. However, as will be readily understood by those skilled in the art, other embodiments besides those disclosed above are also within the scope of this disclosure as defined by the appended claims.

[0062] Therefore, while various aspects and embodiments have been disclosed herein, other aspects and embodiments will be apparent to those skilled in the art. The various aspects and embodiments disclosed herein are for illustrative purposes and are not intended to be limiting, wherein the true scope and spirit are indicated by the appended claims.

Claims

1. A method for distributing data content to receiving devices (11, 12) in a network of trusted data publisher devices (10), comprising: The data content is encrypted (S301) at the trusted data publisher device (10) using a symmetric encryption key shared with the receiving devices (11, 12); The encrypted data content is distributed (S302) from the trusted data publisher device (10) to one of the receiving devices (11). The encrypted data content is received (S303, S307) from one of the receiving devices (11) at another (12) of the receiving devices; Upon request, a subset of the encrypted data content is sent (S304) from the trusted data publisher device (10) to the other (12) of the receiving device; as well as At the other (12) in the receiving device, a verification (S305) is performed to determine whether the subset of the encrypted data content received from the trusted data publisher device (10) matches a selected segment of the encrypted data content received from the one (11) in the network, wherein a match indicates that the encrypted data content received from the one (11) in the receiving device is trustworthy.

2. The method of claim 1, wherein the subset of the encrypted data content has a size less than 1 ppm of the encrypted data content from which the subset is derived.

3. A method for a device (12) to receive data content in a network, comprising: Receive (S303, S307) encrypted data content from another device (11, 14) in the network, the data content having been encrypted with a symmetric key shared with the trusted data publisher device (10); The trusted data publisher device (10) requests (S304) a subset of the encrypted data content received from the other device (11) in the network; Verification (S305) is performed to determine whether the subset of the encrypted data content received from the trusted data publisher device (10) matches a selected segment of the encrypted data content received from the other device (11, 14) in the network, wherein a match indicates that the encrypted data content received from the other device (11) is trustworthy.

4. The method according to claim 3, wherein the verification (S305) of whether the subset of the encrypted data content received from the trusted data publisher device (10) matches the selected segment of the encrypted data content from another device (11) in the network comprises: The subset of the encrypted data content received from the trusted data publisher device (10) is compared with the selected segment of the encrypted data content received from the other device (11), wherein if the subset of the encrypted data content is the same as the selected segment of the encrypted data content, then a match is verified.

5. The method of claim 3 or 4, further comprising, if a match is verified: Decrypt (S306) and present the encrypted data content received from the other device (11), the decryption being performed using the symmetric key shared with the trusted data publisher device (10).

6. The method according to claim 3 or 4, further comprising: Receive a certificate from the trusted data publisher device (10), wherein the trusted data publisher device (10) is considered trusted.

7. The method according to claim 3 or 4, further comprising: The system identifies whether the received encrypted data content is indicated in the manifest file as encrypted data content to be distributed by the trusted data publisher device (10), and if so, requests (S304) the subset of the encrypted data content from the trusted data publisher device (10) as indicated in the manifest file.

8. The method of claim 7, wherein if the received encrypted data content is not indicated in the manifest file as encrypted data content to be distributed by the trusted data publisher device (10), the received encrypted data content is discarded.

9. The method according to claim 3 or 4, wherein the subset of the encrypted data content has a size less than 1 ppm of the encrypted data content from which the subset is derived.

10. A computer program product comprising a computer-readable medium (113) storing computer-executable instructions for causing the trusted data publisher device (10) to perform the steps according to any one of claims 1 to 2 when the computer-executable instructions are executed on a processing unit (111) included in a trusted data publisher device (10).

11. A computer program product comprising a computer-readable medium (213) storing computer-executable instructions for causing the device (12) to perform the steps according to any one of claims 3 to 9 when the computer-executable instructions are executed on a processing unit (211) included in the device (12).

12. A network including a trusted data publisher device (10) configured to distribute data content to receiving devices (11, 12) in the network, the trusted data publisher device (10) including a processing unit (111) and a memory (113) containing instructions (112) executable by the processing unit (111), thereby enabling the trusted data publisher device (10) to: The data content is encrypted using a secret encryption key shared with the receiving devices (11, 12); Distribute the encrypted data content to one of the receiving devices (11). Another (12) of the receiving devices is operable to receive the encrypted data content from one (11) of the receiving devices; The trusted data publisher device (10) is further operable to: send a subset of the encrypted data content to the other (12) of the receiving devices upon request; and At the other (12) of the receiving device, it is verified whether the subset of the encrypted data content received from the trusted data publisher device (10) matches a selected segment of the encrypted data content received from the one (11) of the receiving device in the network, wherein a match indicates that the encrypted data content received from the one (11) of the receiving device is trustworthy.

13. The network of claim 12, wherein the subset of the encrypted data content is configured to have a size less than 1 ppm of the encrypted data content from which the subset is derived.

14. A device (12) configured to receive data content in a network, comprising a processing unit (211) and a memory (213) containing instructions (212) executable by the processing unit (211), thereby enabling the device (12) to: Receive encrypted data content from another device (11, 14) in the network, the data content being encrypted with a symmetric key shared with the trusted data publisher device (10); The trusted data publisher device (10) requests a subset of the encrypted data content received from the other device (11) in the network; Verify whether the subset of the encrypted data content received from the trusted data publisher device (10) matches a selected segment of the encrypted data content received from the other device (11, 14) in the network, wherein a match indicates that the encrypted data content received from the other device (11) is trustworthy.

15. The device (12) of claim 14, when verifying whether the subset of the encrypted data content received from the trusted data publisher device (10) matches the selected segment of the encrypted data content from another device (11) in the network, the device (12) is operable to: The subset of the encrypted data content received from the trusted data publisher device (10) is compared with the selected segment of the encrypted data content received from the other device (11), wherein if the subset of the encrypted data content is the same as the selected segment of the encrypted data content, then a match is verified.

16. The device (12) according to any one of claims 14 or 15, if a match is verified, the device (12) is further operable to: The encrypted data content received from the other device (11) is decrypted and presented, the decryption being performed using the symmetric key shared with the trusted data publisher device (10).

17. The device (12) according to claim 14 or 15 is further operable to: Receive a certificate from the trusted data publisher device (10), wherein the trusted data publisher device (10) is considered trusted.

18. The device (12) according to claim 14 or 15 is further operable to: The system identifies whether the received encrypted data content is indicated in the manifest file as encrypted data content to be distributed by the trusted data publisher device (10), and if so, requests (S304) the subset of the encrypted data content from the trusted data publisher device (10) as indicated in the manifest file.

19. The device (12) of claim 18, wherein if the received encrypted data content is not indicated in the manifest file as encrypted data content to be distributed by the trusted data publisher device (10), the received encrypted data content is discarded.

20. The device (12) according to claim 14 or 15, wherein the subset of the encrypted data content is configured to have a size less than 1 ppm of the encrypted data content from which the subset is derived.

Images