Verification of ciphertext

Abstract

The present disclosure relates to a method for distributing data content in a network by a data issuing device (10) to receiving devices (11, 12), and a method for receiving data content in a network by a device (12), as well as devices (10, 12) performing said method. In one aspect, a method for receiving data content in a network by a device (12) is provided. The method includes receiving encrypted data content from another device (11, 14) in the network (S303, S307), the data content being encrypted using a symmetric key shared with a trusted data content issuer device (10); requesting a subset of the encrypted data content received from the other device (11) in the network from the trusted data content issuer device (10) (S304); and verifying whether the subset of the encrypted data content received from the trusted data content issuer device (10) matches a selected portion of the encrypted data content received from the other device (11, 14) in the network (S305), where a match indicates that the encrypted data content received from the other device (11) may be trusted.

Description

Technical Field

[0001] The present disclosure relates to a method for a data distribution device to distribute data content to a receiving device within a network, a method for a device to receive data content within a network, and a device for performing the method.

Background Art

[0002] In many data distribution scenarios, it is important to verify the received data. One such scenario is when data such as software installers, videos, audio, text content, etc. are stored in untrusted locations of third parties. This includes third-party caching or peer-to-peer (P2P) distribution where the data consumer trusts the data issuer but not necessarily the intermediate data source.

[0003] A common solution is for the data issuer to digitally sign the content or provide another cryptographic hash to enable the end data consumer to securely verify the issuer and / or integrity of the received data.

[0004] If the data issuer does not provide a means to verify the data content, the end data consumer is vulnerable to several cyberattacks ranging from denial-of-service (DoS) attacks to attacks that give intruders full access to the protected system.

[0005] Often, due to technical or organizational reasons, it is complex to change the distribution chain of the data issuer or intermediate data source, and it is desirable to be able to verify the data content of the data issuer without changing any part of the distribution chain.

Summary of the Invention

[0006] One objective is to solve or at least mitigate this problem in the relevant technical field, and thus to provide an improved method for distributing and downloading data content within a network.

[0007] In a first embodiment, this objective is achieved by a method by which a data publishing device distributes data content to receiving devices within a network. This method includes encrypting the data content using a secret encryption key shared with the receiving devices; distributing the encrypted data content to at least one of the receiving devices; and sending a subset of the encrypted data content on request to at least one other receiving device that downloads the encrypted data content from one or more other receiving devices within the network.

[0008] This objective is achieved in a second aspect by a method by which a device receives data content within a network. This method includes receiving encrypted data content from another device within the network, wherein the data content is encrypted using a symmetric key shared with a trusted data content issuer device; requesting a subset of the encrypted data content received from the other device (11) within the network from the trusted data content issuer device; and verifying whether the subset of encrypted data content received from the trusted data content issuer device matches a selection of the encrypted data content received from the other device within the network, wherein the match indicates that the encrypted data content received from the other device can be trusted.

[0009] In a third embodiment, this objective is achieved by a data publishing device configured to deliver data content to receiving devices within a network, the data publishing device comprising a processing unit and memory, the memory including instructions that can be executed by the processing. The data publishing device is operable to encrypt the data content using a secret encryption key shared with the receiving devices, deliver the encrypted data content to at least one of the receiving devices, and send a subset of the encrypted data content on request to at least one other receiving device that downloads the encrypted data content from one or more other receiving devices within the network.

[0010] This objective is achieved in a fourth aspect of the present invention by a device configured to receive data content in a network, the device comprising a processing unit and memory, the memory including instructions (212) executable by the processing unit. The device is operable to: receive encrypted data content from another device in a network, the data content being encrypted using a symmetric key shared with a trusted data content issuer device; request a subset of the encrypted data content received from the other device in the network from the trusted data content issuer device; and verify whether the subset of encrypted data content received from the trusted data content issuer device matches a selection of the encrypted data content received from the other device in the network, the match indicating that the encrypted data content received from the other device (11) can be trusted.

[0011] Therefore, the data publisher distributes pieces of content, called streams or fragments, within the network, encrypted with a symmetric key shared by indented receiving client devices within the network. The encrypted content is distributed, for example, to a first client device, which then distributes the encrypted data content to a second client device. The second client device can then use the shared key to decrypt and subsequently render the content, for example, a video stream.

[0012] However, if a malicious device delivers pieces of malicious content encrypted using the same shared key to a second client, the second client device cannot distinguish whether the encrypted data content, and the resulting decrypted data content (called plaintext), originated from a trusted device or a malicious device. Therefore, because the shared key is used for encryption / decryption, the malicious device can deceive the second client device.

[0013] To overcome this problem, when a second client device receives encrypted data content from the first client device and / or a malicious device, it requests the data issuer to download a subset of the received encrypted content (which typically has an identifier associated with that subset so that the second client device can signal the data issuer about the encrypted data content being requested).

[0014] For example, encrypted data content may be 1GB in size, while a subset constitutes only 256 bits of that 1GB of encrypted content. The subset may 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, and that subset is derived from the encrypted data content.

[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 sets of 256 bits are identical, the data content is considered untampered with, the received encrypted data content is decrypted, and the plaintext data content is rendered on the second client device. If the two sets of 256 bits do not match, the received encrypted data content is discarded.

[0016] Various embodiments of the present invention are described below.

[0017] In general, all terms used in the claims should be interpreted according to their ordinary meaning in the art unless otherwise explicitly defined herein. All references to “elements, apparatus, components, means, steps, etc.” should be openly interpreted as referring to at least one example of an element, apparatus, component, means, step, etc. unless otherwise explicitly stated. The steps of any method disclosed herein do not need to be performed in the exact order disclosed unless otherwise explicitly stated. [Brief explanation of the drawing]

[0018] Herein, aspects and embodiments are described as examples with reference to the attached drawings. [Figure 1] Figure 1 shows a conventional approach to distributing data content within a network. [Figure 2]FIG. 2 shows a malicious device that injects content into a network. [Figure 3] FIG. 3 shows the distribution of data content within a network according to an embodiment. [Figure 4] FIG. 4 shows a flowchart illustrating a method for distributing data content within a network by a data issuer according to an embodiment. [Figure 5] FIG. 5 shows a flowchart illustrating a method for receiving data content within a network by a device according to an embodiment. [[ID=*]] [Figure 6] FIG. 6 shows a flowchart illustrating a method for receiving data content within a network by a device according to another embodiment. [Figure 7] FIG. 7 shows a data issuing device according to an embodiment. [Figure 8] FIG. 8 shows a client device according to an embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0019] Hereinafter, aspects of the present disclosure will be described more fully with reference to the accompanying drawings, in which specific embodiments are shown.

[0020] However, the aspects may be embodied in many different forms and should not be construed as limited. 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. Like numbers refer to like elements throughout the description.

[0021] FIG. 1 shows a problem in the art of distributing data in a P2P scheme (however, this problem is equally relevant to other types of distribution systems).

[0022] [[ID=*]] For example, 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, tablet, etc. in step S101, for example, using the Hypertext Transfer Protocol Secure (HTTPS).

[0023] In this example, the data content is encrypted using a shared key, and the shared key can be provided to the first client device 11 and the second client device 12 by, for example, a digital rights management (DRM) service 13. For example, any suitable encryption algorithm such as the Advanced Encryption Standard (AES) can be employed.

[0024] One advantage in a P2P system is that client devices 11, 12 (usually called 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 a fragment or stream of the encrypted data content downloaded from the data publisher 10 with the second peer device 12 in step 102, while the second peer device 12 can download other fragments of the data content from other peer devices (or from the source 10). The advantage in this approach is that the second peer device 12 does not impose a burden on the data publisher 10 in downloading the data content. Although the embodiments are described with reference to a P2P system, they can be applied in any suitable system where data content is distributed from a source to a client.

[0025] [[ID=十二]]Therefore, the first peer device 11 downloads the encrypted data content from the publisher 10 in step S101, decrypts the encrypted data content using the shared key obtained from the DRM service 13 in step S103, and renders the content on a video player if the data content constitutes video data.

[0026] Accordingly, in step S102, the second peer downloads all or fragments of the encrypted data content shared by the first peer device 11, decrypts the encrypted data content using the same shared key obtained from the DRM service 13 in step S103, and renders the content on the video player. Note that peer devices 12 and 13 do not necessarily download the key from the DRM service 13, but may be pre-configured with the key.

[0027] In Figure 2, if a malicious device 14 accesses a shared key distributed by the DRM service 13, the malicious device 14 can encrypt malicious data (for example, with the purpose of injecting data that would cause inconvenience, or even harm, to a second peer device 12 and / or its user) and distribute the malicious encrypted data to the second peer device 12 (or any other device using the shared key) in step S201.

[0028] Therefore, the malicious device 14 acts as an intermediate data source to inject malicious data encrypted using the correct shared key. Because the correct key is used in symmetric encryption, the second peer device 12 is unable to verify the received encryption fragment.

[0029] Figure 3 shows a solution to this problem provided by an embodiment. Further reference is made to the flowcharts in Figures 4 and 5, which show embodiments provided by the data publisher 10 and the second peer device 12, respectively.

[0030] Therefore, in the first step S301, the data issuer 10 encrypts the data content to be distributed using a key shared with other peer devices 11 and 12 within the network as described above, and in step S302, distributes the encrypted data content to the first peer device 11. In fact, the network may have hundreds, or even thousands, of peer devices, and the issuer 10 typically distributes the encrypted data content directly to multiple peer devices.

[0031] In step S303, the second peer device 12 downloads at least fragments of the encrypted data content downloaded from the data issuer 10 by the first peer device 11 in step S302 from the first peer device 11.

[0032] In order to enable the recipient of the encrypted data content to verify the accuracy of the encrypted data content downloaded in step S303, the recipient (in this case, the second peer device 12) further downloads a smaller subset of the encrypted data content from the original data issuer 10 in step S304. In other words, a target recipient in the distribution network who downloads the data content from another peer device rather than directly from the data issuer 10 further downloads the smaller subset mentioned above from the issuer 10.

[0033] It should be noted that the first peer device 11 does not need the above subset to verify the accuracy of the encrypted data content received in step S302, since it downloads the data content directly from the data issuer 10 rather than downloading it from another peer device. Typically, the first peer device 11 can verify the data issuer 10 using a certificate received from the issuer 10, and therefore, the first peer device 11 can authenticate the received encrypted data content by verifying the digital signature provided to the encrypted data content by the data issuer 10.

[0034] It is understood that the fragments or streams delivered to the second peer device 12 by the first peer device 11 (or malicious device 14) are typically gigabytes (GB) in size, for example, in the range of 2GB to 20GB.

[0035] In contrast, a subset of encrypted data fragments is typically on the order of several hundred bits, for example, 32x8 bits (i.e., 32 bytes). Note that the second peer device 12 receiving the encrypted subset must trust the issuer of the encrypted subset, i.e., the data issuer 10. As mentioned above, the data issuer 10 can guarantee the authenticity of any data downloaded from the data issuer 10 by distributing its certificate to peer devices on the network, thereby providing data with a digital signature. In other words, the data issuer 10 can provide a trusted certificate signed by a root certificate.

[0036] The length of the encrypted data subset determines the level of security, and, much like the length of the encryption key, larger subsets provide stronger security. In terms of security level, an encrypted data subset generally provides the same level of security as a hash function of its corresponding length. Therefore, a 256-bit encrypted data subset provides 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 provides the same level of security as SHA-512.

[0037] As mentioned above, the size of the encrypted data content rendered by the peer device (from which an encrypted data subset is derived) is typically in the range of 1GB to 20GB, while the size of the derived subset is, for example, 128 bits to 512 bits (i.e., 16 bytes to 64 bytes). Therefore, the relationship between the encrypted data content and the encrypted data subset is typically at least 1 × 10⁻¹⁶.9 / 64 = 15,625,000.

[0038] Assuming that a relatively small fragment of encrypted data content, for example 128 megabits, is downloaded, the encrypted data subset derived from the fragment will have a length of 128 bits, but the size of the subset will still be only 1 ppm of the data content.

[0039] Therefore, a small subset of the encrypted data content distributed by the data issuer 10 to the first peer device 11 (and further to the second peer device 12 in step S303) in step S302 is downloaded from the data issuer 10 by the second peer device 12 in step S304. In other words, target recipients in the distribution network who download data content from sources other than the data issuer 10 turn to the data issuer to download the encrypted data subset derived from the downloaded encrypted data content.

[0040] Data issuer 10 is typically identified by a uniform resource locator (URL) contained in a so-called manifest file that is initially delivered to peer devices within the network. This URL identifies data issuer 10 and the data content fragments / streams delivered by data issuer 10. Therefore, when a specific fragment is downloaded in step S303, the second peer device 12 identifies the URL of data issuer 10 in the manifest file for that specific fragment (an identifier matching the corresponding identifier in the manifest file may be provided) and downloads the encrypted data subset in step S304.

[0041] For example, suppose a 1GB piece of data content is encrypted by the data issuer in step S301, distributed to one or more peer devices in the network in step S302, and further, a 32-byte (256-bit) subset of the encrypted data content is downloaded from the data issuer 10 by a peer device that downloads the encrypted data content from other peer devices. The 32-byte subset could be the first or last 32 bytes of the 1GB encrypted data content, or any contiguous 32 bytes of the 1GB content. Hereinafter, the subset is exemplified as the last 32 bytes of the 1GB encrypted data content. It is understood that the second peer device 12 needs to know which part of the encrypted data fragment the subset corresponds to, and this may be pre-configured information for the second peer device 12.

[0042] In step S303, when the encrypted data content is received from the first peer device 11, in step S305, the second peer device 11 checks 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 304 with the last 32 bytes of the received encrypted data content. If the two sets of 32 bytes are identical, the second peer device 12 is assured that the received encrypted data content was indeed originally issued by a trusted data issuer 10 and has not been tampered with.

[0043] A 256-bit encrypted data subset can be used with AES-128, while a 512-bit encrypted subset is used with AES-256. That is, if AES is used by the data issuer 10 as the symmetric encryption scheme, the encrypted data subset downloaded from the data issuer 10 in step 304 may be selected to have a length twice that of the shared symmetric key used for encryption / decryption.

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

[0045] Referring to Figures 3 and 6, if the malicious device 14 provides malicious encrypted data to the second peer device 12 in step S307, the second peer device 12 downloads the encrypted data subset content from the data issuer 10 in step S308 and compares the last 32 bits of the malicious encrypted data with the 32-byte encrypted data subset received from the data issuer 10 in step S309, concluding that a mismatch exists. Here, it is assumed that the malicious device 14 can label the malicious encrypted data with the correct identifier, and as a result, the second peer device 12 can successfully associate the malicious data with the fragment identified in the manifest file so that it actually belongs to the URL of the data issuer 10 (based on the above identifier). If the malicious device 14 provides malicious encrypted data to the second peer device 12 that is not indicated in the manifest file as originating from the data issuer 10, the encrypted data subset is not downloaded in step S308, and the malicious encrypted data is discarded.

[0046] In the art, it should be noted that if a malicious device 14 can provide malicious encrypted data with an identifier that matches a data content fragment of a manifest file, the second peer device 12 will proceed to decrypt the malicious encrypted data because the received malicious encrypted data will appear to actually originate from a trusted URL specified in the manifest file. However, such a spoofing attempt can be detected and successfully avoided by obtaining a subset from the data issuer 10 in step S308 and comparing the subset against a selected portion of the malicious encrypted data in step S309.

[0047] In other words, the 32-byte encrypted data subset received from issuer 10 in step S308 is not identical to the last 32 bytes of the malicious encrypted data received in step S307. Fortunately, the second peer device 12 does not verify the received malicious data in step S309 and therefore does not proceed with decrypting the malicious encrypted data for subsequent execution (which may have fatal consequences). Thus, the verification of the (malicious) encrypted data in step S309 fails, which is the purpose of the encrypted subset provided by data issuer 10.

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

[0049] As a result, it is computationally impossible to create malicious plaintext under the same encryption key that generates partially identical ciphertext. In other words, it is computationally impossible for the malicious device 14 to encrypt the plaintext such that a 32-byte sequence of ciphertext results in ciphertext corresponding to a 32-byte subset of encrypted data created by the data issuer 10.

[0050] Typically, in this technical field, security issues are resolved by requiring data issuers to apply asymmetric signatures or use hashes, which requires the corresponding actions to be performed on the peer device.

[0051] Figure 7 shows a data issuing device 10 according to an embodiment, where the steps of the method performed by the data issuing device 10 are actually performed 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 associated with a microprocessor, such as random access memory (RAM), flash memory, or a hard disk drive. The processing unit 111 is arranged to cause the data issuing device 10 to execute the method according to the embodiment once a suitable computer program 112 comprising computer executable instructions has been downloaded to the storage medium 113 and executed by the processing unit 111. The storage medium 113 may also be a computer program product containing the computer program 112. Alternatively, the computer program 112 may be transferred to the storage medium 113 by a suitable computer program product such as a digital versatile disk (DVD) or memory stick. As a further alternative, the computer program 112 may be downloaded to the storage medium 113 over a network. Alternatively, the processing unit 111 may be implemented in the form of a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or a complex-programmable logic device (CPLD). The data issuing device 10 further comprises a communication interface 114 (wired or wireless), and the data issuing device 10 is configured to transmit and receive data via the communication interface 114.

[0052] Figure 8 shows a client device 12 according to an embodiment, where the steps of the method performed by the client device 12 are actually performed 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 associated with a microprocessor, such as RAM, flash memory, or a hard disk drive. The processing unit 211 is arranged to cause the client device 12 to execute the method according to the embodiment once a suitable computer program 212 comprising computer executable instructions has been downloaded to the storage medium 213 and executed by the processing unit 211. The storage medium 213 may also be a computer program product containing the computer program 212. Alternatively, the computer program 212 may be transferred to the storage medium 213 by a suitable computer program product such as a DVD or memory stick. As a further alternative, the computer program 212 may be downloaded to the storage medium 213 over a network. Alternatively, the processing unit 211 may be embodied in the form of a DSP, ASIC, FPGA, CPLD, etc. The client device 12 further includes a communication interface 214 (wired or wireless), and the client device 12 is configured to transmit and receive data via the communication interface 214.

[0053] The aspects of this disclosure are described above primarily with reference to several embodiments and examples thereof. However, it will be readily apparent to those skilled in the art that other embodiments not described above are also possible within the scope of this disclosure, as defined by the appended claims.

[0054] Accordingly, although various aspects and embodiments are disclosed herein, other aspects and embodiments will be obvious to those skilled in the art. The various aspects and embodiments disclosed herein are for illustrative purposes only and are not intended to be limiting, and the true scope and spirit are set forth by the following claims. The inventions disclosed herein include the following: [Aspect 1] A method for distributing data content to receiving devices (11, 12) within a network using a data issuing device (10), Encrypting the data content using a secret encryption key shared with the receiving devices (11, 12) (S301), Distributing encrypted data content to at least one of the receiving devices (11) (S302), The process involves sending a subset of the encrypted data content to at least one other receiving device (12) that downloads the encrypted data content from one or more other receiving devices (11) within the network, upon request (S304), Methods that include... [Aspect 2] The method according to embodiment 1, wherein the subset of the encrypted data content has a size of less than 1 ppm of the encrypted data content, and the subset is derived from the encrypted data content. [Aspect 3] A method for receiving data content within a network by a device (12), Receiving encrypted data content from another device (11, 14) within the aforementioned network (S303, S307), wherein the data content is encrypted using a symmetric key shared with a trusted data content issuer device (10), Requesting the trusted data content publisher device (10) for a subset of the encrypted data content received from the other device (11) within the network (S304), S305) verifies whether the subset of the encrypted data content received from the trusted data content issuer device (10) matches a selected portion of the encrypted data content received from another device (11, 14) within the network, wherein the match indicates that the encrypted data content received from the other device (11) is trustworthy. Methods that include... [Aspect 4] The confirmation (S305) of whether the subset of encrypted data content received from the trusted data content publisher device (10) matches the selected portion of encrypted data content from another device (11) in the network is: The method of embodiment 3, comprising comparing the subset of the encrypted data content received from the trusted data content issuer device (10) with the selected portion of the encrypted data content received from the other device (11), wherein a match is confirmed if the subset of the encrypted data content is identical to the selected portion of the encrypted data content. [Aspect 5] If a match is confirmed, The method according to any one of aspects 3 or 4, further comprising decrypting (S306) and rendering the encrypted data content received from the other device (11), wherein the decryption is performed using the symmetric key shared with the trusted data content issuer device (10). [Aspect 6] The method according to any one of embodiments 3 to 5, further comprising receiving a certificate from the data issuer device (10), wherein the data issuer device (10) is considered trustworthy. [Aspect 7] The method according to any one of embodiments 3 to 6, further comprising: identifying whether the received encrypted data content is indicated in the manifest file as encrypted data content to be distributed by the trusted data issuer device (10); and, if identified, requesting the trusted data issuer device (10) to provide the subset of the encrypted data content indicated in the manifest file (S304). [Aspect 8] The method according to aspect 7, wherein if the received encrypted data content is not indicated in the manifest file as encrypted data content distributed by the trusted data issuer device (10), the received encrypted data content is discarded. [Aspect 9] The method according to any one of embodiments 3 to 8, wherein the subset of the encrypted data content has a size of less than 1 ppm of the encrypted data content, and the subset is derived from the encrypted data content. [Aspect 10] A computer program (112) comprising a computer executable instruction that, when executed on a processing unit (111) included in a data issuing device (10), causes the data issuing device (10) to perform the steps described in any one of embodiments 1 to 2. [Aspect 11] A computer program product comprising a computer-readable medium (113), wherein the computer-readable medium has a computer program (112) as described in embodiment 10, which is realized on the computer-readable medium. [Aspect 12] A computer program (112) comprising a computer executable instruction that, when executed on a processing unit (211) included in the device (12), causes the device (12) to perform the steps described in any one of embodiments 3 to 9. [Aspect 13] A computer program product comprising a computer-readable medium (213), wherein the computer-readable medium has a computer program (212) as described in embodiment 12, which is realized on the computer-readable medium. [Aspect 14] A data publishing device (10) configured to distribute data content to receiving devices (11, 12) within a network, comprising a processing unit (111) and a memory (113), wherein the memory includes instructions (112) that can be executed by the processing unit (111), and the data publishing device (10) The data content is encrypted using a secret encryption key shared with the receiving devices (11, 12). The encrypted data content is delivered to at least one of the receiving devices (11), A data publishing device (10) that downloads the encrypted data content from one or more other receiving devices (11) within the network, and is operable to transmit a subset of the encrypted data content to at least one other receiving device (12) upon request. [Aspect 15] The subset of the encrypted data content is configured to have a size of less than 1 ppm of the encrypted data content, and the subset is derived from the encrypted data content, the data issuing device (10) according to embodiment 14. [Aspect 16] A device (12) configured to receive data content within a network, comprising a processing unit (211) and a memory (213), wherein the memory includes instructions (212) that can be executed by the processing unit (211), the device (12) The process involves receiving encrypted data content from another device (11, 14) within the aforementioned network, wherein the data content is encrypted using a symmetric key shared with a trusted data content issuer device (10), Requesting a subset of the encrypted data content received from the other device (11) within the network from the trusted data content publisher device (10), Device (12) is operable to perform the following: verify whether the subset of encrypted data content received from the trusted data content publisher device (10) matches a selection of the encrypted data content received from another device (11, 14) in the network, wherein the match indicates that the encrypted data content received from the other device (11) can be trusted. [Aspect 17] When verifying whether the subset of encrypted data content received from the trusted data content publisher device (10) matches the selected portion of encrypted data content from another device (11) in the network, A device (12) according to embodiment 16, which is operable to compare the subset of encrypted data content received from the trusted data content publisher device (10) with the selected portion of the encrypted data content received from the other device (11), wherein a match is confirmed if the subset of the encrypted data content is identical to the selected portion of the encrypted data content. [Aspect 18] If a match is confirmed, A device (12) according to any one of embodiments 16 or 17, further operable to decrypt and render the encrypted data content received from the other device (11), wherein the decryption is performed using the symmetric key shared with the trusted data content issuer device (10). [Aspect 19] The device (12) is further operable to receive a certificate from the data issuer device (10), wherein the data issuer device (10) is a device (12) according to any one of embodiments 16 to 18, which is considered trustworthy. [Aspect 20] A device (12) according to any one of embodiments 16 to 19, further operable to identify whether the received encrypted data content is indicated in the manifest file as encrypted data content distributed by the trusted data issuer device (10), and if so, to request the subset of the encrypted data content indicated in the manifest file from the trusted data issuer device (10) (S304). [Aspect 21] If the received encrypted data content is not indicated in the manifest file as encrypted data content distributed by the trusted data issuer device (10), the received encrypted data content is discarded, device (12) according to aspect 20. [Aspect 22] The subset of the encrypted data content is configured to have a size of less than 1 ppm of the encrypted data content, and the subset is a device (12) according to any one of embodiments 16 to 21 derived from the encrypted data content.

Claims

1. A method in a network for distributing data content to receiving devices (11, 12) within a network by a data publisher device (10), The data issuer device (10) encrypts the data content using a symmetric encryption key shared with the receiving devices (11, 12) (S301), The data issuer device (10) distributes the encrypted data content to one of the receiving devices (11) (S302), Another of the receiving devices (12) receives the encrypted data content from one of the receiving devices (11) (S303, S307), The data issuer device (10) transmits a subset of the encrypted data content to one of the receiving devices (12) upon request (S304), One of the receiving devices (12) recognizes a selected portion of the encrypted data content received from one of the receiving devices (11) within the network that corresponds to the subset of the encrypted data content received from the data issuer device (10), and confirms whether the subset of the encrypted data content received from the data issuer device (10) matches the selected portion (S305), wherein a match indicates that the encrypted data content received from one of the receiving devices (11) is trustworthy. Methods that include...

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

3. A method for receiving data content within a network by a device (12), Receiving encrypted data content from another device (11, 14) within the aforementioned network (S303, S307), wherein the data content is encrypted using a symmetric key shared with a trusted data issuer device (10), Requesting the trusted data issuer device (10) to provide a subset of the encrypted data content received from the other device (11) within the network (S304), The process involves recognizing a selected portion of the encrypted data content received from the other devices (11, 14) within the network that corresponds to the subset of the encrypted data content received from the data issuer device (10), and confirming whether the subset of the encrypted data content received from the data issuer device (10) matches the selected portion (S305), wherein a match indicates that the encrypted data content received from the other device (11) is trustworthy. Methods that include...

4. The confirmation (S305) of whether the subset of the encrypted data content received from the trusted data issuer device (10) matches the selected portion is: The method of claim 3, comprising comparing the subset of encrypted data content received from the trusted data issuer device (10) with the selected portion, wherein a match is confirmed if the subset of encrypted data content is identical to the selected portion.

5. If a match is confirmed, The method according to any one of claims 3 or 4, further comprising decrypting (S306) and rendering the encrypted data content received from the other device (11), wherein the decryption is performed using the symmetric key shared with the trusted data issuer device (10).

6. The method according to any one of claims 3 or 4, further comprising receiving a certificate from the data issuer device (10), wherein the data issuer device (10) is considered trustworthy.

7. The method according to any one of claim 3 or 4, further comprising: identifying whether the received encrypted data content is indicated in the manifest file as encrypted data content to be distributed by the trusted data issuer device (10); and, if identified, requesting the trusted data issuer device (10) to provide the subset of the encrypted data content indicated in the manifest file (S304).

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

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

10. A computer program (112) comprising a computer executable instruction that, when executed on a processing unit (111) included in a data issuer device (10), causes the data issuer device (10) to perform the method according to any one of claims 1 to 2.

11. A computer program product comprising a computer-readable medium (113), wherein the computer-readable medium has a computer program (112) according to claim 10 that is realized on the computer-readable medium.

12. A computer program (212) comprising a computer executable instruction that, when executed on a processing unit (211) included in a device (12), causes the device (12) to perform the method according to any one of claims 3 or 4.

13. A computer program product comprising a computer-readable medium (213), wherein the computer-readable medium comprises a computer program (212) according to claim 12, which is realized on the computer-readable medium.

14. A network comprising a data issuer device (10), wherein the data issuer device (10) is configured to distribute data content to receiving devices (11, 12) within the network, and the data issuer device (10) comprises a processing unit (111) and a memory (113), wherein the memory includes instructions (112) that can be executed by the processing unit (111), and the data issuer device (10) is configured to distribute data content to receiving devices (11, 12) within the network, The data content is encrypted using a secret encryption key shared with the receiving devices (11, 12). It is capable of distributing encrypted data content to one of the receiving devices (11), Another of the receiving devices (12) is operable to receive the encrypted data content from one of the receiving devices (11), The data issuer device (10) is further operable to send a subset of the encrypted data content to another of the receiving devices (12) upon request. A network in which one of the receiving devices (12) recognizes a selected portion of the encrypted data content received from one of the receiving devices (11) within the network that corresponds to the subset of the encrypted data content received from the data issuer device (10), and checks whether the subset of the encrypted data content received from the data issuer device (10) matches the selected portion, and a match indicates that the encrypted data content received from one of the receiving devices (11) can be trusted.

15. The network according to claim 14, wherein the subset of the encrypted data content is configured to have a size of less than 1 ppm of the encrypted data content, and the subset is derived from the encrypted data content.

16. A device (12) configured to receive data content within a network, comprising a processing unit (211) and a memory (213), wherein the memory includes instructions (212) that can be executed by the processing unit (211), the device (12) The process involves receiving encrypted data content from another device (11, 14) within the aforementioned network, wherein the data content is encrypted using a symmetric key shared with a trusted data issuer device (10), Requesting a subset of the encrypted data content received from the other device (11) within the network from the trusted data issuer device (10), Device (12) is operable to recognize a selected portion of the encrypted data content received from another device (11, 14) within the network that corresponds to the subset of the encrypted data content received from the data issuer device (10), and to verify whether the subset of the encrypted data content received from the data issuer device (10) matches the selected portion, wherein a match indicates that the encrypted data content received from the other device (11) is trustworthy.

17. When verifying whether the subset of the encrypted data content received from the trusted data issuer device (10) matches the selected portion, The device (12) according to claim 16, which is operable to compare the subset of encrypted data content received from the trusted data issuer device (10) with the selected portion, wherein a match is confirmed if the subset of encrypted data content is identical to the selected portion.

18. If a match is confirmed, The device (12) according to claim 16, further operable to decrypt and render the encrypted data content received from the other device (11), wherein the decryption is performed using the symmetric key shared with the trusted data issuer device (10).

19. The device (12) according to claim 16, which is further operable to receive a certificate from the data issuer device (10), wherein the data issuer device (10) is considered trustworthy.

20. The device (12) according to claim 16, further operable to identify whether the received encrypted data content is indicated in the manifest file as encrypted data content to be distributed by the trusted data issuer device (10), and if so, to request the subset of the encrypted data content indicated in the manifest file from the trusted data issuer device (10) (S304).

21. If the received encrypted data content is not indicated in the manifest file as encrypted data content distributed by the trusted data issuer device (10), the received encrypted data content is discarded, device (12) according to claim 20.

22. The subset of the encrypted data content is configured to have a size of less than 1 ppm of the encrypted data content, and the subset is derived from the encrypted data content, the device (12) according to any one of claims 16 to 21.

Images