Threshold Encryption for Broadcast Content

Abstract

An exemplary operation includes dividing a session key into multiple partial shares, distributing the multiple partial shares to multiple content providers, each of which receives a different partial share of the session key, encrypting a stream of media content based on the session key, and transmitting the encrypted stream of digital content to a user device having one or more of the multiple partial shares.

Description

[Background technology]

[0001] A centralized platform stores and maintains data in a single location. This location is often a central computer, such as a cloud computing environment, a web server, a mainframe computer, etc. Information stored in a centralized platform is typically accessible from multiple different locations. Multiple users or client workstations can work simultaneously on the centralized platform, for example, based on a client / server configuration. A centralized platform is easier to manage, maintain, and control, especially from a security perspective, because of its single location. Data redundancy is minimized within a centralized platform, as storing all data in a single location means having only one primary record for a given data set. Summary of the Invention [Means for solving the problem]

[0002] One exemplary embodiment provides an apparatus comprising: a processor configured to perform one or more of: dividing a session key into multiple partial shares; distributing the multiple partial shares respectively to multiple content providers (where each content provider receives a different partial share of the session key); and encrypting a stream of media content based on the session key; and a network interface configured to transmit the encrypted stream of digital content to a user device having one or more of the multiple partial shares.

[0003] Another exemplary embodiment provides a method including one or more of: dividing a session key into multiple partial shares; distributing the multiple partial shares respectively to multiple content providers (where each content provider receives a different partial share of the session key); encrypting a stream of media content based on the session key; and transmitting the encrypted stream of digital content to a user device having one or more partial shares of the multiple partial shares.

[0004] A further exemplary embodiment provides a non-transitory computer-readable medium comprising instructions that, when read by a processor, cause the processor to perform one or more of the following methods, including dividing a session key into multiple partial shares, distributing the multiple partial shares respectively to multiple content providers (where each content provider receives a different partial share of the session key), encrypting a stream of media content based on the session key, and transmitting the encrypted stream of digital content to a user device having one or more of the multiple partial shares. [Brief explanation of the drawings]

[0005] [Figure 1] FIG. 1 is a diagram illustrating a computing environment for broadcast encryption, according to an exemplary embodiment. [Figure 2A] FIG. 2A is a diagram illustrating an example blockchain architecture configuration, according to an example embodiment. [Figure 2B] FIG. 2B is a diagram illustrating a blockchain transaction flow between multiple nodes, according to an example embodiment. [Figure 3A] FIG. 3A is a diagram illustrating a permissioned network, according to an example embodiment. [Figure 3B]FIG. 3B is a diagram illustrating another permissioned network according to an example embodiment. [Figure 3C] FIG. 3C is a diagram illustrating a permissionless network, according to an example embodiment. [Figure 4A] FIG. 4A is a diagram illustrating a process for distributing shares of a session key according to an example embodiment. [Figure 4B] FIG. 4B illustrates a process for broadcasting content based on the session key according to an example embodiment. [Figure 4C] FIG. 4C illustrates another process for distributing shares of the session key according to another exemplary embodiment. [Figure 4D] FIG. 4D illustrates another process for broadcasting content based on the session key according to an example embodiment. [Figure 5] FIG. 5 is a diagram illustrating a method for broadcast encryption according to an exemplary embodiment. [Figure 6A] FIG. 6A illustrates an example system configured to perform one or more of the operations described herein, according to an example embodiment. [Figure 6B] FIG. 6B illustrates another example system configured to perform one or more of the operations described herein, according to an example embodiment. [Figure 6C] FIG. 6C illustrates a further exemplary system configured to utilize smart contracts, according to an exemplary embodiment. [Figure 6D] FIG. 6D illustrates yet another exemplary system configured to utilize blockchain, according to an exemplary embodiment. [Figure 7A] FIG. 7A illustrates a process by which a new block is added to a distributed ledger, according to an example embodiment. [Figure 7B]FIG. 7B is a diagram illustrating the data contents of the new data block, according to an exemplary embodiment. [Figure 7C] FIG. 7C is a diagram illustrating a blockchain for digital content, according to an example embodiment. [Figure 7D] FIG. 7D is a diagram illustrating a block that may represent the structure of a block in the blockchain, according to an example embodiment. [Figure 8A] FIG. 8A illustrates an example blockchain for storing machine learning (artificial intelligence) data, according to an example embodiment. [Figure 8B] FIG. 8B is a diagram illustrating an exemplary quantum-secure blockchain, according to an exemplary embodiment. [Figure 9] FIG. 9 illustrates an exemplary system that supports one or more of the exemplary implementations. DETAILED DESCRIPTION OF THE INVENTION

[0006] It will be readily understood that instant components, as generally described and illustrated in the figures accompanying this specification, may be arranged and designed in a wide variety of different configurations. Thus, the following detailed description of at least one embodiment of a method, apparatus, non-transitory computer-readable medium, and system, as represented in the accompanying figures, is not intended to limit the scope of the present invention as claimed, but is merely representative of selected embodiments.

[0007] Features, structures, or characteristics of the invention as described throughout this specification may be combined or eliminated in any suitable manner in one or more embodiments. For example, throughout this specification, the use of the phrase "exemplary embodiment," "some embodiments," or other similar language indicates the fact that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment. Thus, the appearance of "exemplary embodiment," "some embodiments," "other embodiments," or other similar language throughout this specification does not necessarily refer to the same group of embodiments, but rather that the described features, structures, or characteristics may be combined or eliminated in any suitable manner in one or more embodiments. Furthermore, in the figures, any connection between elements can enable communication in one direction or two directions, or a combination thereof, even if the depicted connection is a one-way or two-way arrow. Also, any devices depicted in the figures can be different devices. For example, when a mobile device is shown transmitting information, a wired device can also be used to transmit information.

[0008] Additionally, although the term "message" may be used in describing the embodiments, the present invention may apply to many types of networks and data. Furthermore, although certain types of connections, messages, and signaling are depicted in the exemplary embodiments, the present invention is not limited to certain types of connections, messages, and signaling.

[0009] Exemplary embodiments provide a method, system, component, non-transitory computer-readable medium, device, or network, or combination thereof, directed to a broadcast encryption system based on threshold encryption. In exemplary embodiments, digital content protected by digital rights management (DRM) rules can be encrypted and then broadcast to multiple consumer devices.

[0010] In some embodiments, the system may rely on a session key that can be used for both encryption and decryption. As another example, the session key may be a symmetric key pair, where one key (e.g., a public key) is used for encryption and another key (e.g., a private key) is used for decryption. In an exemplary embodiment, rather than using a single decryption key, the session key (e.g., the key used to decrypt encrypted content) is divided or split into multiple secret keys or partial shares using threshold encryption. Because the system uses threshold encryption, the session key can be recovered with a predefined number (e.g., a majority) of the partial shares without requiring all of the partial shares.

[0011] The fractional shares may be distributed among multiple content providers so that each content provider receives its own unique fractional share of the session key. The content providers may comprise organizations that produce content in digital form, such as music, movies, software, etc. Each content provider may register its own set of users / user devices for downloading and playing individual pieces of content. During the registration process, the content provider may provide the fractional shares to the user devices for storage. The user devices may register with most or all of the content providers to obtain enough fractional shares to be able to reconstruct the session key and decrypt the pieces of content.

[0012] Each content provider may store its list of registered users on a blockchain, where the content provider may also be a participant (blockchain peer) in the blockchain. Through the blockchain, each of the content providers can track the registered user lists of all other content providers. Furthermore, each content provider can provide its respective list of registered users to a broadcast platform, e.g., a streaming service.

[0013] The broadcaster may aggregate users from the registered user list and broadcast a piece of content to the aggregated group of users. For a user device to be able to decrypt the content, it must have enough fractional shares to reconstruct the session key and decrypt the encrypted content based on the reconstructed session key. However, if a user device does not have enough fractional shares, it will not be able to recover the session key and decrypt the content.

[0014] Exemplary embodiments improve upon prior art broadcast encryption systems by partitioning the encryption / decryption scheme using threshold encryption. For example, it is possible for an unauthorized user to gain access to a content provider (and the content provider's corresponding fractional shares). Here, the unauthorized user could be a hacker or other malicious actor. However, access to the content provider and each fractional share would not be sufficient for the unauthorized user to decrypt the broadcast content because the user would only have one fractional share and would not have the threshold number of fractional shares necessary to reconstruct the session key and decrypt the content. As another example, a malicious actor may misappropriate a fractional share intended for a registered user from a content provider. In this case, the registered user may not receive the fractional share. However, if the registered user has sufficient fractional shares from other content providers, the registered user could still recover the session key.

[0015] In one embodiment, the present invention utilizes a decentralized database (e.g., a blockchain), which is a distributed storage system with multiple nodes communicating with each other. The decentralized database includes an append-only immutable data structure, similar to a distributed ledger, that can maintain records between mutually untrusted parties. The untrusted parties are referred to herein as peers or peer nodes. Each peer maintains a copy of the database record, and a single peer cannot modify the database record unless consensus is reached among the distributed peers. For example, the peers may execute a consensus protocol to validate storage transactions in the blockchain, group the storage transactions into blocks, and build a hash chain over the blocks. This process creates a ledger by ordering the storage transactions as necessary for consistency. In various embodiments, a permissioned blockchain, a permissionless blockchain, or a combination thereof can be used. In public or permissionless blockchains, anyone can participate without a specific identity. Public blockchains can include native cryptocurrencies and use consensus based on various protocols, such as Proof of Work (PoW), while permissioned blockchain databases provide secure interaction between groups of entities that share a common goal, such as a business exchanging funds, goods, or information, but do not fully trust each other.

[0016] The present invention can utilize blockchain to run arbitrary programmable logic tailored to a decentralized storage scheme, known as "smart contracts" or "chaincodes." In some cases, specialized chaincodes exist for managing functions and parameters, referred to as system chaincodes. The present invention can also utilize smart contracts, which are trusted distributed applications that leverage the tamper-resistant properties of blockchain databases and a fundamental agreement between nodes, known as an "endorsement" or "endorsement policy." Blockchain transactions associated with this application can be "endorsed" before being committed to the blockchain, while unendorsed transactions are ignored. The endorsement policy allows the chaincode to specify endorsers for a transaction in the form of a set of peer nodes required for endorsement. When a client sends a transaction to a peer specified in the endorsement policy, the transaction is executed for validation. After the validation, the transactions enter the ordering phase, where a consensus protocol is used to generate an ordered sequence of endorsed transactions grouped into blocks.

[0017] The present invention may utilize nodes, which are communicating entities in a blockchain system. A "node" may perform a logical function, in the sense that multiple nodes of different types can run on the same physical server. Nodes are grouped into trust domains and associated in various ways with logical entities that control them. Nodes may be of different types, such as client or submitting client nodes that submit transaction invocations to endorsers (e.g., peers) and broadcast transaction proposals to ordering services (e.g., ordering nodes). Another type of node is a peer node, which can receive transactions submitted by clients, commit the transactions, and maintain a copy of the blockchain transaction state and ledger. Peers may also, but are not required to, have the role of endorser. An ordering service node, or orderer, is a node that performs communication services for all nodes and implements delivery guarantees, such as broadcasting to each of the peer nodes in the system, when committing transactions and modifying the blockchain world state; it is another name for the initial blockchain transaction, which usually contains control and configuration information.

[0018] The present invention can utilize a ledger, which is a sequenced, tamper-resistant record of all state transitions of a blockchain. State transitions can result from chaincode invocations (i.e., transactions) submitted by participating parties (client nodes, ordering nodes, endorser nodes, peer nodes, etc.). Each participant (e.g., peer node) can maintain a copy of the ledger. A transaction can result in a set of asset key-value pairs being committed to the ledger as one or more operands, e.g., create, update, delete, etc. The ledger includes a blockchain (also referred to as a chain) used to store immutable sequenced records in blocks. The ledger also includes a state database that maintains the current state of the blockchain.

[0019] The present invention can utilize a chain, which is a transaction log structured as hash-linked blocks, where each block contains a sequence of N transactions, where N is 1 or greater. The block header contains a hash of the block's transactions and a hash of the previous block's header. In this way, all transactions on the ledger may be sequenced and cryptographically linked together. Therefore, it is impossible to tamper with the ledger data without breaking the hash links. The hash of the most recently added blockchain block represents all transactions on the chain that preceded it, allowing all peer nodes to ensure a consistent and trusted state. The chain may be stored on the peer node's file system (i.e., local storage, attached storage, cloud, etc.), efficiently supporting the append-only nature of blockchain workloads.

[0020] The current state of an immutable ledger represents the most recent values ​​for all keys contained in the chain transaction log. The current state is referred to as the world state because it represents the most recent key values ​​known to the channel. Chaincode invocations execute transactions against the ledger's current state data. To make these chaincode interactions efficient, the most recent key values ​​may be stored in a state database. The state database may be an indexed view into the chain's transaction log, so it can be regenerated from the chain at any time. The state database may be automatically restored (or generated as needed) upon peer node startup and before transactions are accepted.

[0021] Broadcast encryption is the process of distributing encrypted content (e.g., TV shows, DVDs, Blu-rays, MP3s, etc.) over a broadcast channel so that only registered users (e.g., subscribers) can decrypt the content. Rather than directly encrypting the content for each user, broadcast encryption schemes distribute key information that allows registered users to reconstruct an encryption key (or decryption key) and decrypt the content, while revoked or other unauthorized users do not have enough information to recover the key. The difficulty with broadcast encryption is ensuring that only registered users can decrypt the broadcast content.

[0022] In an exemplary embodiment, each content provider is responsible for maintaining a list of registered users. The list may be stored on the blockchain. However, the partial shares (e.g., split session keys) controlled by the content provider are not stored on the blockchain and remain private to the content provider.

[0023] FIG. 1 illustrates a computing environment 100 for broadcast encryption according to an exemplary embodiment. Referring to FIG. 1, a broadcast encryption system (i.e., a broadcaster 120) is configured to broadcast content to multiple user devices 131-134 over a channel, e.g., an Internet network connection. In this example, the broadcaster 120 may be a central host system, e.g., a streaming platform, a cloud computing environment, a web server, a database, etc., that transmits content to the user devices 131-134. Meanwhile, each user device 131-134 may be a computing system, television, vehicle, home appliance, etc., capable of playing media, multimedia, digital content, etc., such as audio, video, documents, files, software programs, etc.

[0024] The computing environment 100 also includes multiple content providers 111-113 that produce or otherwise provide the media / content that is broadcast to the user devices 131-134 by the broadcaster 120. For example, the content providers 111-113 may be movie studios, digital media manufacturers, platform owners, etc., that own or otherwise control the content that is being broadcast.

[0025] Before the content is broadcast to user devices 131-134, the content may be encrypted by the broadcaster 120 using a broadcast encryption key, also referred to herein as a session key. In some embodiments, the session key may refer to a key that can be used to both encrypt and decrypt the digital content. In this example, the session key may be split into multiple partial keys (shares) and distributed to multiple content providers 111-113. Each content provider 111-113 may receive a different partial share of the session key. As another example, the session key may be a symmetric key pair that includes both a private key and a public key. The private key may be split into multiple shares and distributed to content providers 111-113 so that each content provider receives a different share of the secret. Here, the public key may be used by broadcaster 120 to encrypt content, and the private key may be used to decrypt the encrypted content.

[0026] For example, the session key may be divided into N fractional shares. In some embodiments, K may correspond to the number of content providers participating in the system. Each content provider will receive a unique fractional share. To reconstruct the session key, a user must obtain at least K fractional shares (where K is less than N). For example, N may be equal to 10 and K may be equal to 6. Here, each user must obtain at least 6 of the 10 fractional shares before recovering the session key and decrypting the broadcast content. On the other hand, if a user obtains K or fewer fractional shares, the user will not be able to recover the session key. Thus, if the user obtains 5 or fewer fractional shares, the user will not be able to decrypt the broadcast content.

[0027] Examples of threshold encryption schemes include, but are not limited to, Shamir's Secret Sharing.

[0028] Before user device 131 (or any of user devices 131-134) can decrypt broadcast content being downloaded from broadcaster 120, user device 131 must obtain enough partial shares of the session key from enough content providers 111-113 to satisfy a threshold encryption scheme. In other words, user device 131 must obtain enough partial shares of the session key to recover the session key and, ultimately, decrypt the broadcast content using the recovered session key. As a non-limiting example, the threshold may be a majority of the partial shares, although embodiments are not limited in this respect. The threshold may be any desired number. In this example, there are three content providers 111-113. As an example, user device 131 may need at least two of the three partial shares to reconstruct the session key.

[0029] According to various embodiments, content providers 111-113 may implement a blockchain network among themselves, with each content provider 111-113 being a blockchain peer that maintains a copy of blockchain 110 (e.g., a distributed blockchain ledger). Content providers 111-113 may store a list of users on blockchain 110. In some embodiments, the list may comprise a different subset of user devices than other user devices, although there will likely be many overlapping users. User devices 131-134 will want to register with as many content providers 111-113 as possible. Therefore, each list may be said to be a subset of registered users of the broadcast content. Registered users are considered authorized to consume and decrypt the content. Here, content provider 111 stores a first user list (List A) on blockchain 110. Similarly, content provider 112 stores a second list (List B), and content provider 113 stores a third list (List C). Moreover, the list may be updated over time, for example, to add new users, revoke users, etc.

[0030] As further described below with respect to FIG. 4A, each of the user devices 131-134 may pre-register with one or more of the content providers 111-113. During the registration process, the user devices 131-134 receive a partial share of the session key (i.e., a respective partial share from each registered content provider). Thus, each of the user devices 131-134 will obtain a subset of the partial shares. In some cases, the subset may include all partial shares, but this is not always the case.

[0031] For user device 131 (or any of user devices 131-134) to decrypt broadcast content received from broadcaster 120, user device 131 must have a sufficient partial share of the session key to recover the session key according to a threshold encryption scheme. Once the session key is recovered, user device 131 may decrypt and play or otherwise consume the content.

[0032] The broadcaster 120 may receive respective lists (List A, List B, and List C) from the content providers 111-113 at periodic or continuous intervals. Each list may be specific to a particular portion of content that is continuously updated based on new users, revoked users, etc. The lists may include identification information for each user device, such as IP address, device ID, username, email, user address, phone number, etc. The broadcaster 120 may identify all unique user devices (e.g., by IP address, device ID, username, email, phone number, etc.) that have registered to use the portion of content from the lists provided by the content providers 111-113. The broadcaster may aggregate and identify all users from all lists and then send a broadcast signal with the content stored therein to all identified users. For example, even if a user device is listed on only one of the three lists, the broadcaster 120 will still broadcast a signal containing the encrypted content. However, only user devices 131-134 that obtain a sufficient partial share of the session key will be able to recover the session key and decrypt the encrypted content.

[0033] FIG. 2A illustrates a blockchain architecture configuration 200 according to an exemplary embodiment. Referring to FIG. 2A, the blockchain architecture 200 may include a group of blockchain elements, e.g., blockchain nodes 202. The blockchain nodes 202 may include one or more nodes 204-210 (these four nodes are illustrated by way of example only). These nodes participate in a number of activities, such as adding and validating blockchain transactions (consensus). One or more of the blockchain nodes 204-210 may endorse transactions based on endorsement policies and provide ordering services for all blockchain nodes in the architecture 200. The blockchain nodes may initiate blockchain validations and seek to write to a blockchain immutable ledger stored in a blockchain layer 216, a copy of which may also be stored on the underlying physical infrastructure 214. A blockchain configuration may comprise one or more applications 224 linked to an application programming interface (API) 222 to access and execute stored program / application code 220 (e.g., chaincode, smart contracts, etc.), which can be created according to customized configurations desired by participants, maintain their own state, control their own assets, and receive external information, which can be deployed as transactions and installed on all blockchain nodes 204-210 via appending to the distributed ledger.

[0034] The blockchain base or platform 212 may include various layers of blockchain data, services (e.g., cryptographic trust services, virtual execution environments, etc.), and underlying physical computer infrastructure that may be used to receive and store new transactions and provide access to auditors seeking access to data entries. The blockchain layer 216 may process program code and expose interfaces that provide access to the virtual execution environments necessary to participate in the physical infrastructure 214. The cryptographic trust services 218 may be used to verify transactions, such as asset exchange transactions, and to keep information private.

[0035] The blockchain architecture of FIG. 2A may process and execute program / application code 220 through one or more interfaces and services exposed by the blockchain platform 212. The code 220 may control blockchain assets. For example, the code 220 may store and transfer data and may be executed by the nodes 204-210 in the form of smart contracts and associated chaincode having conditions or other code elements that govern their execution. As a non-limiting example, the smart contracts may be created to implement reminders, updates, or other notifications regarding changes or updates, or a combination thereof. The smart contracts themselves may be used to identify authorization and access requirements and rules associated with ledger usage. For example, the smart contracts (or chaincodes executing the smart contract logic) may read blockchain data 226 that can be processed by one or more processing entities (e.g., virtual machines) included in the blockchain layer 216 to generate results 228 within composite service scenarios, such as results 228 described above, including alerts, liability determinations, etc. The physical infrastructure 214 may be utilized to obtain any of the data or information described herein.

[0036] Smart contracts may be created via high-level application and programming languages ​​and then written into blocks within a blockchain. The smart contracts may comprise executable code that is registered, stored, or replicated on the blockchain (e.g., a decentralized network of blockchain peers), or a combination thereof. A transaction is an execution of smart contract logic that may be executed in response to a condition associated with the smart contract being satisfied.

[0037] Execution of the smart contract may trigger one or more trusted modifications to the state of a digital blockchain ledger, which may be automatically replicated across a decentralized network of blockchain peers through one or more consensus protocols.

[0038] The smart contract may write data to the blockchain in key-value pair format. Additionally, smart contract code can read values ​​stored in the blockchain and use them in application operations. The smart contract code can write the output of various logical operations into one or more blocks in the blockchain. The code can be used to create temporary data structures within a virtual machine or other computing platform. Data written to the blockchain can be public, or encrypted and kept private, or a combination thereof can be implemented. The temporary data used / generated by the smart contract is kept in memory by the provided execution environment and then deleted as data needed for the blockchain is identified.

[0039] Chaincode may comprise a code interpretation (e.g., logic) of a smart contract. For example, the chaincode may comprise a packaged and deployable version of the logic in the smart contract. As described herein, the chaincode may be program code deployed on a computing network, where it is executed together and verified by a chain validator during a consensus process. The chaincode may receive a hash and retrieve from the blockchain a hash associated with a data template generated by use of a previously stored feature extractor. If the hash of the hashed identifier and the hash created from the stored identifier template data match, the chaincode sends an authorization key to the requested service. The chaincode may write data associated with cryptographic details to the blockchain.

[0040] FIG. 2B illustrates an example of a blockchain transaction flow 250 between nodes of the blockchain, according to an exemplary embodiment. Referring to FIG. 2B, the transaction flow may include a client node 260 sending a transaction proposal 291 to an endorsing peer node 281. The endorsing peer node 281 may verify the client signature and execute a chaincode function to initiate the transaction. The output may include the chaincode result, a set of key / value versions read by the chaincode (the read set), and a set of key / value versions written by the chaincode (the write set). The endorsing peer 281 may then decide whether to endorse the transaction proposal. If approved, a proposal response 292 is sent back to the client 260 along with an endorsement signature. The client 260 assembles the endorsement into a transaction payload 293 and broadcasts it to the ordering service node 284. The ordering service node 284 then distributes the ordered transaction as a block to all peers 281-283 on the channel. Before committing it to the blockchain, each peer 281-283 may validate the transaction. For example, the peer may check an endorsement policy to ensure that the correct allocation of designated peers signed the result and authenticated the signature against the transaction payload 293.

[0041] Referring again to FIG. 2B , the client node initiates a transaction 291 by formulating and sending a request to the endorser peer node 281. The client 260 may have an application that leverages a supported software development kit (SDK), which uses available APIs to generate a transaction proposal. The proposal is a request to invoke chaincode functions so that data is read, written, or read and written to the ledger (i.e., writing a new key-value pair for an asset). The SDK packages the transaction proposal in a well-designed format (e.g., protocol buffers over remote procedure calls (RPCs)) and can serve as a shim to obtain the client's cryptographic credentials and generate a unique signature for the transaction proposal. In response, the endorsing peer node 281 may verify that (a) the transaction proposal is well-formed, (b) the transaction has not already been submitted previously (replay-attack protection), (c) the signature is valid, and (d) the submitter (client 260 in the example) is properly authorized to perform the proposed action on the channel. The endorsing peer node 281 may receive the transaction proposal input as an argument to the invoked chaincode function.

[0042] The chaincode is then executed against the current state database to produce the transaction results, e.g., a response value, a read set, and a write set. However, no updates are made to the ledger at this point. In step 292, the set of values, along with the signature of the endorsing peer node 281, is returned as a proposal response 292 to the client 260's SDK, which parses the payload for consumption by the application.

[0043] In response, the application at client 260 checks / verifies the signature of the endorsing peer and compares the proposed response to determine whether it is the same. If the chaincode only queried the ledger, the application would check the query response and typically would not submit the transaction to the ordering node service 284. When a client application intends to submit a transaction to the ordering node service 284 to update the ordering node service, the application determines whether the specified endorsement policy has been satisfied (i.e., whether all required peer nodes for the transaction have endorsed the transaction) before submission. Here, the client may include only one of multiple parties to the transaction. In this case, each client may have its own endorsing node, and each endorsing node must endorse the transaction. The architecture ensures that the endorsement policy will be enforced by peers and upheld in the commit verification phase, even if the application chooses not to check the response or otherwise forwards an unendorsed transaction.

[0044] After successful validation, in step 293, client 260 assembles the endorsements into a transaction proposal and broadcasts the transaction proposal and response in a transaction message to ordering node 284. The transaction may include a read / write set, an endorsement peer signature, and a channel ID. Ordering node 284 does not need to validate the entire content of the transaction to perform its action; instead, ordering node 284 may simply receive transactions from all channels in the network, order them chronologically by channel, and create blocks of transactions for each channel.

[0045] The block is distributed from the ordering node 284 to all peer nodes 281-283 on the channel. Data sections within the block may be validated to ensure endorsement policies are met and to ensure that no changes have been made to the ledger state for the readset variable since the readset was generated by the transaction execution. Furthermore, in step 295, each peer node 281-283 appends the block to the channel's chain, and for each valid transaction, a writeset is committed to the current state database. An event may be emitted to notify the client application that the transaction (invocation) has been immutably appended to the chain, and whether the transaction has been validated or invalidated.

[0046] 3A illustrates an example of a permissioned blockchain network 300 featuring a distributed, decentralized, peer-to-peer architecture. In this example, a blockchain user 302 may initiate a transaction against a permissioned blockchain 304. In this example, the transaction may be a deploy, invoke, or query, and may be issued through a client-side application utilizing an SDK, directly through an API, or the like. The network may provide access to regulators 306, e.g., auditors. A blockchain network operator 308 manages member permissions, e.g., registering regulators 306 as "auditors" and blockchain users 302 as "clients." Auditors may be limited to only querying the ledger, while clients may be allowed to deploy, invoke, and query certain chaincodes.

[0047] A blockchain developer 310 can write chaincode and client-side applications. The blockchain developer 310 can deploy the chaincode directly to the network through an interface. To include credentials from a traditional data source 312 in the chaincode, the developer 310 can use an out-of-band connection to access the data. In this example, a blockchain user 302 connects to the permissioned blockchain 304 through a peer node 314. Before proceeding with any transactions, the peer node 314 obtains the user's enrollment and transaction certificate from a certificate authority 316, which manages user roles and permissions. In some cases, a blockchain user must possess these digital certificates to transact on the permissioned blockchain 304. However, a user attempting to use chaincode may be required to verify the user's credentials with the traditional data source 312. To confirm the user's authorization, the chaincode can use an out-of-band connection to this data through a traditional processing platform 318.

[0048] 3B shows another example of a permissioned blockchain network 320 featuring a distributed, decentralized, peer-to-peer architecture. In this example, blockchain users 322 may submit transactions to a permissioned blockchain 324. In this example, the transactions may be deploys, invokes, or queries, and may be issued through client-side applications leveraging SDKs or directly through APIs, etc. The network may provide access to regulators 326, e.g., auditors. A blockchain network operator 328 manages member permissions, e.g., registering regulators 326 as "auditors" and blockchain users 322 as "clients." Auditors may be limited to only querying the ledger, while clients may be allowed to deploy, invoke, and query certain chaincodes.

[0049] A blockchain developer 330 can write chaincode and client-side applications. The blockchain developer 330 can deploy the chaincode directly to the network through an interface. To include credentials from a traditional data source 332 in the chaincode, the developer 330 can use an out-of-band connection to access the data. In this example, a blockchain user 322 connects to the network through a peer node 334. Before proceeding with any transaction, the peer node 334 obtains the user's enrollment and transaction certificate from a certificate authority 336. In some cases, a blockchain user must possess these digital certificates to transact on the permissioned blockchain 324. However, a user attempting to use chaincode may be required to verify the user's credentials with the traditional data source 332. To confirm the user's authentication, the chaincode can use an out-of-band connection to this data through a traditional processing platform 338.

[0050] In some embodiments, the blockchain herein may be a permissionless blockchain. In contrast to a permissioned blockchain, which requires permission to participate, anyone can participate in a permissionless blockchain. For example, to participate in a permissionless blockchain, a user may create a personal address and begin interacting with the network by submitting transactions, thus adding entries to the ledger. Additionally, all parties have the option to run a node on the system and validate transactions using a mining protocol.

[0051] 3C illustrates a transaction process 350 processed by a permissionless blockchain 352 comprising multiple nodes 354. A sender 356 wishes to send a payment or some other form of value (e.g., a certificate, medical records, a contract, goods, services, or any other asset that can be encapsulated in a digital record) to a recipient device 358 via the permissionless blockchain 352. In one embodiment, the sender device 356 and the recipient device 358 may each have a digital wallet (associated with the blockchain 352) that provides user interface controls and an indication of transaction parameters. In response, the transaction is broadcast throughout the blockchain 352 to the nodes 354. Depending on the network parameters of the blockchain 352, the nodes validate the transaction 360 based on rules (which may be predefined or dynamically assigned) established by the creator of the permissionless blockchain 352. For example, this may include verifying the identities of the parties, etc. The transaction may be validated immediately or may be placed in a queue with other transactions, and node 354 may determine whether the transaction is valid based on a set of network rules.

[0052] In structure 362, valid transactions are formed into blocks and sealed with a lock (hash). This process may be performed by mining nodes among nodes 354. Mining nodes may utilize additional software specifically for mining and creating blocks for the permissionless blockchain 352. Each block may be identified by a hash (e.g., a 256-bit number) created using an algorithm agreed upon by the network. Each block may include a header, a pointer or reference to the hash of the header of the previous block in the chain, and a group of valid transactions. The reference to the hash of the previous block is associated with creating a secure, independent chain of blocks.

[0053] Before a block can be added to the blockchain, it must be verified. Verification for a permissionless blockchain 352 may comprise proof-of-work (PoW), which is the solution to a puzzle derived from the block's header. Although not shown in the example of FIG. 3C, another process for validating blocks is proof-of-stake. Unlike proof-of-work, where an algorithm rewards miners for solving a mathematical problem, in proof-of-stake, the creator of a new block is selected in a deterministic manner depending on their wealth, also defined as "stake." A similar proof is then performed by the selected / elected node.

[0054] In mining 364, nodes attempt to solve a block by making incremental changes to one variable until the solution meets the network-wide goal. This creates proof of work, which guarantees a correct answer. In other words, potential solutions must prove that computing resources were expended in solving the problem. In some types of permissionless blockchains, miners may earn value (e.g., coins) for successfully mining a block.

[0055] Here, the PoW process, along with the chaining of blocks, makes it extremely difficult to modify the blockchain because an attacker must modify all subsequent blocks to accept a modification to a block. Furthermore, as new blocks are mined, the difficulty of modifying the block increases, and the number of subsequent blocks increases. Through distribution 366, successfully validated blocks are distributed throughout the permissionless blockchain 352, and all nodes 354 add the block to the majority chain, which is an auditable ledger of the permissionless blockchain 352. Furthermore, value in the transaction submitted by the sender 356 is deposited into the digital wallet of the recipient device 358 or transferred in other ways.

[0056] FIG. 4A shows a process 400A for distributing shares of a session key according to an exemplary embodiment, and FIG. 4B shows a process 400B for broadcasting content based on the session key according to an exemplary embodiment. Referring to FIG. 4A, a broadcaster 410 divides a session key 420 into multiple partial shares 420A, 420B, 420C, and 420D corresponding to multiple content providers 431, 432, 433, and 434, respectively. The broadcaster then distributes each partial share to each of the content providers 431-434. For example, content provider 431 receives partial share 420A, content provider 432 receives partial share 420B, content provider 433 receives partial share 420C, and content provider 434 receives partial share 420D. To recover session key 420, the user device must obtain at least three of the four shares (any three of 420A, 420B, 420C, and 420D).

[0057] 4A, each user device 441, 442, and 443 registers with each of the content providers 431-434 and, during the registration process, obtains a respective partial share 420A, 420B, 420C, and 420D from each of the content providers 431, 432, 433, and 434. Here, the user devices 441-443 may register via an online interface, portal, or website, or by mail or telephone, while the respective partial share is delivered via electronic means, e.g., email, downloadable file, etc.

[0058] Referring now to FIGURE 4B, a broadcaster 410 may encrypt a stream of digital content using a session key 420 and then broadcast the stream of digital content (in encrypted form) to all user devices 441-443. In the example of FIGURE 4B, user device 443 receives the encrypted stream of digital content and attempts to reconstruct session key 420. Now, because user device 443 has all shares (420A-420D) of session key 420, user device 443 can reconstruct session key 420 and decrypt the stream of digital content. Thus, user device 443 can consume the stream of content, which may include, for example, live or on-demand television, movies, music, etc.

[0059] FIG. 4C shows another process 400C for distributing shares of a session key according to another exemplary embodiment, and FIG. 4D shows another process 400D for broadcasting content based on the session key according to an exemplary embodiment. Referring to FIG. 4C, content provider 434 has been compromised by unauthorized user 444. In this example, unauthorized user 444 may be a hacker or other unregistered user who has gained unauthorized access to partial key share 420D controlled by content provider 434. In this example, unauthorized user 444 has added its own device to the list of registered users registered with content provider 434 and removed registered user 443, who had granted access to partial key share 420D.

[0060] In this example, partial key share 420D may be updated after modifications made by unauthorized user 444 and then given to all registered users. Thus, unauthorized user 444 may receive updated partial key share 420D, while registered user 443 may not. However, referring to FIG. 4D , even though updated partial key share 420D is no longer owned by registered user 443, registered user 443 may still be able to recover the session key. In particular, registered user 443 still has most of partial shares 420A, 420B, and 420C and can reconstruct session key 420.

[0061] On the other hand, unauthorized users 444 only have access to partial share 420D and are unable to reconstruct session key 420. Therefore, unauthorized users 444 are unable to decrypt the broadcast content. Thus, the security of broadcast encryption is significantly enhanced through the threshold encryption scheme used by the present system, as unauthorized users are prevented from illegally obtaining copies of the digital content, while authorized users can continue to receive the content even if their access rights are restricted by the unauthorized user.

[0062] FIG. 5 illustrates broadcast encryption of a method 500 according to an exemplary embodiment. As a non-limiting example, method 500 may be performed by a cloud platform, a server, a blockchain peer, a database, etc. Referring to FIG. 5 , at step 510, the method includes splitting a session key into multiple partial shares. For example, each key may be split into multiple partial shares. Each share may be unique. Here, the splitting may be performed based on a threshold encryption scheme in which a predefined number of partial shares are required to recover the session key. In some embodiments, the splitting may include splitting the session key into a number of partial shares equal to the number of content providers. In some embodiments, the session key may be recoverable from a predefined number of partial shares, and the predefined number of partial shares may be greater than two and less than all of the partial shares.

[0063] At step 520, the method includes respectively distributing the plurality of partial shares to a plurality of content providers, where each content provider receives a different partial share of the session key. Meanwhile, at step 530, the method includes encrypting a stream of media content based on the session key, and at step 540, transmitting the encrypted stream of digital content to user devices having one or more of the plurality of partial shares. In some embodiments, the transmitting includes simultaneously transmitting the encrypted stream of digital content from a host platform to a plurality of user devices over a computing network.

[0064] In some embodiments, the method further includes receiving, via a blockchain, a list of registered user devices that are registered with the stream of digital content, and the transmitting includes broadcasting the encrypted stream of digital content to the list of registered user devices received from the blockchain. In some embodiments, the blockchain may include multiple blockchain peers, and each blockchain peer may serve a different respective subset of multiple registered user devices. In some embodiments, the single session key includes a private key of a symmetric key pair that is divided into the multiple fractional shares, and the encrypting includes encrypting the stream of digital content using a public key of the symmetric key pair.

[0065] FIG. 6A illustrates an example system 600 including a physical infrastructure 610 configured to perform various operations according to example embodiments. Referring to FIG. 6A, the physical infrastructure 610 includes a module 612 and a module 614. The module 614 includes a blockchain 620 and a smart contract 630 (which may reside on the blockchain 620), which may perform any of the operational steps 608 (in module 612) included in any of the example embodiments. The steps / operations 608 may include one or more of the described or depicted embodiments and may represent output or written information written to or read from one or more smart contracts 630 or the blockchain 620, or a combination thereof. The physical infrastructure 610, the module 612, and the module 614 may include one or more computers, servers, processors, memories, or wireless communication devices, or a combination thereof. Furthermore, the modules 612 and 614 may be the same module.

[0066] FIG. 6B illustrates another exemplary system 640 configured to perform various operations according to exemplary embodiments. Referring to FIG. 6B, system 640 includes module 612 and module 614. Module 614 includes a blockchain 620 and a smart contract 630 (which may reside on blockchain 620) and may perform (in module 612) any of the operational steps 608 included in any of the exemplary embodiments. Steps / operations 608 may include one or more of the described or depicted embodiments and may represent output or written information written to or read from one or more smart contracts 630 or blockchain 620, or a combination thereof. Physical infrastructure 610, module 612, and module 614 may include one or more computers, servers, processors, memories, or wireless communication devices, or a combination thereof. Furthermore, module 612 and module 614 may be the same module.

[0067] FIG. 6C illustrates an exemplary system configured to utilize a smart contract configuration between contracting parties and an intermediary server configured to enforce the smart contract terms on a blockchain, according to an exemplary embodiment. Referring to FIG. 6C, configuration 650 may represent a communication session, an asset transfer session, or a process or procedure driven by a smart contract 630 that explicitly identifies one or more user devices 652 or 656, or a combination thereof. The operation and results of smart contract execution may be managed by a server 654. The content of the smart contract 630 may require digital signatures by one or more entities 652 and 656 that are parties to the smart contract transaction. The results of smart contract execution may be written to the blockchain 620 as a blockchain transaction. The smart contract 630 resides on the blockchain 620, which may reside on one or more computers, servers, processors, memories, or wireless communication devices, or a combination thereof.

[0068] FIG. 6D illustrates a system 660 with a blockchain, according to an exemplary embodiment. Referring to the example of FIG. 6D , an application programming interface (API) gateway 662 provides a common interface for accessing blockchain logic (e.g., smart contract 630 or other chaincode) and data (e.g., a distributed ledger, etc.). In this example, the API gateway 662 is a common interface for performing transactions (calls, queries, etc.) on the blockchain by connecting one or more entities 652 and 656 to a blockchain peer (i.e., server 654). Here, server 654 is a blockchain network peer component that holds a copy of the world state and a distributed ledger that allows clients 652 and 656 to query data in the world state and submit transactions to the blockchain network, where endorsing peers execute smart contract 630 depending on the smart contract 630 and endorsement policies.

[0069] The above embodiments may be implemented in hardware, in a computer program executed by a processor, or in a combination thereof. The computer program may be embodied on a computer-readable medium, such as a storage medium. For example, the computer program may reside in any form of storage medium known in the art, such as a random access memory (RAM), flash memory, read-only memory (ROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), registers, a hard disk, a removable disk, a compact disk read-only memory (CD-ROM), or the like.

[0070] An exemplary storage medium may be coupled to the processor such that the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor. The processor and the storage medium may reside in an application specific integrated circuit ("ASIC"). In the alternative, the processor and the storage medium may reside as discrete components.

[0071] FIG. 7A illustrates a process 700 for a new block to be added to a distributed ledger 720 according to an exemplary embodiment, and FIG. 7B illustrates the contents of a new data block structure 730 for the blockchain according to an exemplary embodiment. Referring to FIG. 7A, a client (not shown) may submit a transaction to blockchain nodes 711, 712, or 713, or a combination thereof. The client may receive instructions from any source to perform an activity on the blockchain 722. As an example, the client may be an application acting on behalf of a requester, e.g., a device, person, or entity, proposing a transaction for the blockchain. Multiple blockchain peers (e.g., blockchain nodes 711, 712, and 713) may maintain copies of the blockchain network state and the distributed ledger 720. Different types of blockchain nodes / peers may exist in the blockchain network, including endorsing peers that simulate and endorse transactions proposed by clients, and committing peers that verify the endorsements, validate the transactions, and commit the transactions to the distributed ledger 720. In this example, blockchain nodes 711, 712, and 713 may perform the role of endorser nodes, committer nodes, or both.

[0072] The distributed ledger 720 comprises a blockchain, which stores immutable, sequenced records in blocks, and a state database 724 (current world state) that maintains the current state of the blockchain 722. One distributed ledger 720 may exist per channel, and each peer maintains its own copy of the distributed ledger 720 for each channel of which it is a member. The blockchain 722 is a transaction log structured as hash-linked blocks, where each block contains a sequence of N transactions. A block may comprise various components as shown in FIG. 7B. The block links (shown by arrows in FIG. 7A) may be generated by adding a hash of the previous block's header into the current block's block header. In this way, all transactions on the blockchain 722 are sequenced and cryptographically linked, preventing tampering with the blockchain data without breaking the hash links. Furthermore, because of the links, the latest block of the blockchain 722 represents all transactions that came before it. The blockchain 722 may be stored on a peer file system (local storage or attached storage) that supports append-only blockchain workloads.

[0073] The current state of the blockchain 722 and distributed ledger 720 may be stored in a state database 724, where the current state data represents the latest values ​​for all keys ever included in the chain transaction log of the blockchain 722. Chaincode invocations execute transactions against the current state in the state database 724. To make these chaincode interactions highly efficient, the latest values ​​for all keys are stored in the state database 724. The state database 724 may comprise an indexed view into the blockchain 722 transaction log, and therefore, it can be regenerated from the chain at any time. The state database 724 may be automatically restored (or generated as needed) upon peer initiation before transactions are accepted.

[0074] An endorsing node receives a transaction from a client and endorses the transaction based on the simulation results. The endorsing node holds a smart contract that simulates a transaction proposal. When an endorsing node endorses a transaction, it creates a transaction endorsement, which is a signed response from the endorsing node to the client application indicating the endorsement of the simulated transaction. The manner in which a transaction is endorsed depends on the endorsement policy, which may be specified in the chaincode. An example of an endorsement policy is "a majority of endorsing peers must endorse the transaction." Different channels may have different endorsement policies. The endorsed transaction is forwarded by the client application to the ordering service 710.

[0075] The ordering service 710 accepts endorsed transactions, orders them into blocks, and distributes the blocks to committing peers. For example, the ordering service 710 may initiate a new block when a transaction threshold has been reached, when a timer times out, or under other conditions. In the example of Figure 7A, blockchain node 712 is a committing peer that has received a new data block 730 for storage in blockchain 722. The first block in the blockchain may be called a genesis block, which contains information about the blockchain, its members, the data stored therein, etc.

[0076] The ordering service 710 may be composed of a cluster of orderers. The ordering service 710 does not process transactions, smart contracts, or maintain a distributed ledger. Rather, the ordering service 710 may accept endorsed transactions and specify the order in which those transactions are committed to the distributed ledger 720. The architecture of the blockchain network may be designed so that specific implementations of "ordering" (e.g., Solo, Kafka, BFT, etc.) are pluggable components.

[0077] Transactions are written to the distributed ledger 720 in a consistent order. The order of transactions is established to ensure that updates to the state database 724 are valid when committed to the network. Unlike cryptocurrency blockchain systems (e.g., Bitcoin) where ordering occurs through solving cryptographic puzzles, i.e., mining, in this example, the parties to the distributed ledger 720 can choose the ordering mechanism that best suits their network.

[0078] When the ordering service 710 initializes a new data block 730, the new data block 730 may be broadcast to the committing peers (e.g., blockchain nodes 711, 712, and 713). In response, each committing peer validates the transaction in the new data block 730 by verifying that the read set and write set still match the world state in the state database 724. Specifically, the committing peer can determine whether the read data that existed when the endorser simulated the transaction is identical to the current world state in the state database 724. When the committing peer validates the transaction, the transaction is written to the blockchain 722 on the distributed ledger 720, and the state database 724 is updated with the write data from the read set and write set. If a transaction fails, i.e., if the committing peer finds that the read set and write set do not match the current world state in state database 724, the transaction will still be included in the block but will be marked as invalid and state database 724 will not be updated.

[0079] Referring to Figure 7B, a new data block 730 (also referred to as a data block) stored on the blockchain 722 of a distributed ledger 720 may comprise multiple data segments, such as a block header 740, block data 750 (block data section), and block metadata 760. It should be understood that the various depicted blocks and their contents, such as the new data block 730 and their contents shown in Figure 7B, are merely illustrative and are not meant to limit the scope of the illustrative embodiments. In a conventional block, the data section may store transaction information for N transactions (e.g., 1, 10, 100, 500, 1000, 2000, 3000, etc.) within the block data 750.

[0080] The new data block 730 may include a link to a previous block (e.g., on the blockchain 722 in FIG. 7A) in its block header 740. In particular, the block header 740 may include a hash of the previous block's header. The block header 740 may also include a unique block number, a hash of the block data 750 of the new data block 730, etc. The block numbers of the new data block 730 may be unique, as well as assigned in various orders, e.g., incremental / consecutive orders starting from zero.

[0081] According to various embodiments, block data 750 may store a registered user list 752 for the digital content. For example, each blockchain peer may store its own respective subset of registered users for that blockchain peer. In some embodiments, user list 752 may include updates to a previously stored user list 752 for the content. That is, updates may be stored in user list 752 via the blockchain. According to various embodiments, user list 752 may be stored in an immutable log of blocks on distributed ledger 720. Some of the advantages of storing user list 752 on the blockchain are reflected in various embodiments disclosed and depicted herein. While user list 752 is depicted in block data 750 in FIG. 7B , in other embodiments, user list 752 may be located in block header 740 or block metadata 760.

[0082] Block metadata 760 may store multiple fields of metadata (e.g., as a byte array, etc.). The metadata fields may include a signature at the time of block creation, a reference to the last constituent block, a transaction filter that identifies valid and invalid transactions in the block, the last persisted offset of the ordering service that ordered the block, etc. The signature, last constituent block, and orderer metadata may be added by the ordering service 710.

[0083] Meanwhile, the block committer (e.g., blockchain node 712) may add validity / invalidity information based on endorsement policies, verification of read / write sets, etc. The transaction filter may include a byte array of size equal to the number of transactions included in the block data 750 and a verification code that identifies whether the transaction was valid / invalid.

[0084] FIG. 7C shows an embodiment of a blockchain 770 for digital content, consistent with embodiments described herein. The digital content may comprise one or more files and associated information. The files may comprise media, images, video, audio, text, links, graphics, animations, web pages, documents, or other forms of digital content. The immutable, append-only aspect of the blockchain serves as a safeguard to protect the integrity, validity, and authenticity of the digital content, and is appropriately used in legal proceedings where admissibility rules apply, or other settings where evidence is considered or otherwise concerned with the presentation and use of digital information. In this case, the digital content may be referred to as digital evidence.

[0085] The blockchain may be formed in a variety of ways. In one embodiment, the digital content may be contained in and accessed from the blockchain itself. For example, each block of the blockchain may store a hash value of reference information (e.g., headers, values, etc.) along with associated digital content. The hash value and associated digital content may then be encrypted together. Thus, the digital content of each block may be accessed by decrypting each block in the blockchain, and the hash value of each block may be used as a reference to refer to previous blocks. This may be illustrated as follows:

[0086] [Table 1]

[0087] In one embodiment, the digital content may not be included within the blockchain. For example, the blockchain may store an encrypted hash of the content of each block without including any of the digital content. The digital content may be stored in another storage area or memory address in association with the hash value of the original file. The other storage area may be the same storage device used to store the blockchain, or it may be a different storage area, or even a different relational database. The digital content of each block may be referenced or accessed by obtaining or querying the hash value of the block of interest and then searching for that hash value in the storage area where it is stored in association with the actual digital content. This operation may be performed, for example, by a database gatekeeper. This may be illustrated as follows:

[0088] [Table 2]

[0089] In the exemplary embodiment of FIG. 7C, a blockchain 770 comprises multiple blocks 7781, 7782, ..., 7783 that are cryptographically linked in an ordered sequence. N where N≧1. Blocks 7781, 7782, ..., 778 N The encryption used to concatenate blocks 7781, 7782, ..., 778 can be any of a number of keyed or un-keyed hash functions. N are subjected to a hash function that generates an n-bit alphanumeric output (where n is 256 or another number) from input based on the information in the block. Examples of such hash functions include, but are not limited to, SHA-type (SHA stands for Secured Hash Algorithm) algorithms, Merkle-Damgard algorithms, HAIFA algorithms, Merkle-tree algorithms, nonce-based algorithms, and non-collision-resistant PRF algorithms. In another embodiment, blocks 7781, 7782, ..., 778 N may be cryptographically concatenated by a function different from the hash function. For purposes of explanation, the following description is made with reference to a hash function, e.g., SHA-2.

[0090] Blocks 7781, 7782, ..., 778 in the blockchain N Each of the file versions includes a header, a file version, and a value. The header and the value are different for each block as a result of hashing in the blockchain. In one embodiment, the value may be included in the header. As described in more detail below, the file version may be the original file or a different version of the original file.

[0091] The first block 7781 of the blockchain is referred to as the genesis block and includes a header 7721, an original file 7741, and an initial value 7761. The hashing scheme used for the genesis block may actually change for all subsequent blocks. For example, all of the information in the first block 7781 may be hashed together at once, or each or portions of the information in the first block 7781 may be hashed separately, and then a hash of the separately hashed portions may be performed.

[0092] The header 7721 may include one or more initial parameters, such as a version number, a timestamp, a nonce, route information, a difficulty level, a consensus protocol, a duration, a media format, a source, descriptive keywords, or other information associated with the original file 7741 or the blockchain, or other information associated with the original file 7741 and the blockchain, or a combination thereof. The header 7721 may be generated automatically (e.g., by blockchain network management software) or manually by a blockchain participant. Other blocks 7781-7782 in the blockchain N Unlike the headers in , the header in the genesis block 7721 does not reference a previous block, simply because there is no previous block.

[0093] The original file 7741 in the genesis block may be, for example, data captured by a device with or without processing before inclusion in the blockchain. The original file 7741 may be received from a device, media source, or node through an interface of the system. The original file 7741 may be associated with metadata, which may be generated either manually or automatically by, for example, a user, a device, or a system processor, or a combination thereof. The metadata may be included in the first block 7781 associated with the original file 7741.

[0094] The value 7761 in the genesis block is an initial value generated based on one or more unique attributes of the original file 7741. In one embodiment, the one or more unique attributes may comprise a hash value for the original file 7741, metadata for the original file 7741, and other information associated with the file. In one implementation, the initial value 7761 may be based on the following unique attributes: 1) The SHA-2 calculated hash value for the original file 2) Source device ID 3) The start timestamp for the original file 4) The initial storage location of the original file 5) The blockchain network member ID for the software that currently controls the original file and associated metadata.

[0095] Other blocks 7782 to 778 of the same blockchain N However, unlike the first block 7721, the headers 7722 to 7723 in the other blocks N Each of the Nth blocks contains the hash value of the immediately preceding block, which may be just the hash value of the immediately preceding block's header, or the hash value of the entire immediately preceding block. By including the hash value of the immediately preceding block in each of the remaining blocks, it is possible to trace back block by block from the Nth block to the generating block (and associated original file), as indicated by arrow 780, establishing an auditable and immutable chain of custody.

[0096] Headers 7722 to 772 in other blocks Nmay include other information, such as a version number, a timestamp, a nonce, root information, a difficulty level, a consensus protocol, or other parameters or information associated with the corresponding file or blockchain in general, or the corresponding file and blockchain in general, or a combination thereof.

[0097] Files 7742 to 774 in the other blocks N may be identical to the original file or may be a modified version of the original file in the genesis block, depending on, for example, the type of processing performed. The type of processing performed may vary from block to block. The processing may include any modification of the file in the preceding block, changing its content, for example, editing information, or otherwise modifying its content such as removing information from, adding information to, or appending information to the file.

[0098] Additionally or alternatively, the processing may include simply copying a file from a previous block, changing the storage location of the file, parsing a file from one or more previous blocks, moving a file from one storage or memory location to another, or performing an operation associated with the file or its associated metadata or a combination thereof in the blockchain. Processing involving parsing the file may include, for example, appending, including, or otherwise associating various analytical, statistical, or other information associated with the file.

[0099] Values ​​7762 to 776 in each block of other blocks Nare unique values ​​and are all different as a result of the operations performed. For example, the value in any one block represents an updated version of the value in the previous block. The update is reflected in the hash of the block to which the value is assigned. A block's value therefore indicates what operations have been performed in that block and allows tracing back through the blockchain to the original file. This tracing confirms the chain of custody of a file throughout the blockchain.

[0100] For example, consider the case where a portion of a file in a previous block is redundant, blocked out, or pixelated to protect the identity of a person depicted in the file. In this case, the block containing the redundant file would include metadata associated with the redundant file, such as how the redundancy was performed, who performed the redundancy, timestamps of one or more locations where redundancy was performed, etc. This metadata may be hashed to form a value. Because the metadata for the block is different from the information hashed to form the value in the previous block, the values ​​will be different and may be recovered when restored.

[0101] In one embodiment, the value of a previous block may be updated (e.g., a new hash value may be calculated) to form the value of a current block when any one or more of the following occurs: The new hash value, in this example embodiment, may be calculated by hashing all or part of the information listed below: a) If the file has been processed in any way (e.g., if the file has been edited, copied, modified, accessed, or any other action performed on it), a new SHA-2 calculated hash value b) A new storage location for the file c) Identified new metadata associated with the file. d) Transfer of access to or control of the file from one blockchain participant to another blockchain participant

[0102] 7D illustrates one embodiment of a block that may represent the structure of multiple blocks in a blockchain 790, according to one embodiment. The block, i.e., block i, includes a header 772. i , File 774 i , and value 776 i It is equipped with:

[0103] Header 772 i is the previous block, i.e. Block i-1 , and additional reference information, which may be, for example, any type of information discussed herein (e.g., header information including references, properties, parameters, etc.). Every block, except of course for the genesis block, references the hash of the previous block. The hash value of the previous block may be just the hash of the header in the previous block, or it may be a hash of all or part of the information in the previous block, including the files and metadata.

[0104] File 774i includes a plurality of data, e.g., Data1, Data2, ..., DataN, in order. The data are tagged with Metadata1, Metadata2, ..., MetadataN, which describe content or characteristics associated with the data, or a combination thereof. For example, the metadata for each data may include information indicating a timestamp for the data, information processing the data, keywords indicating people or other content depicted in the data, or other features that may be useful for establishing the validity and content of the file as a whole, such as digital evidence use, or a combination thereof, as described in connection with the embodiments discussed below, among others. In addition to the metadata, each data may include a reference to previous data, i.e., Reference1, Reference2, ..., Reference3, to prevent tampering, gaps in the file, and sequential referencing through the file. N(REF1,REF2,...,REF N ) can be tagged.

[0105] Once the metadata is assigned to the data (e.g., through a smart contract), it cannot be changed without a hash change, which can be easily identified for invalidation. Thus, the metadata creates a data log of information that can be accessed for use by participants in the blockchain.

[0106] Value 776 i is a hash value or other value calculated based on any of the types of information previously discussed. For example, for any given block, i In this case, the value of that block, such as a new hash value, a new storage location, new metadata about the associated file, a control or access transfer, an identifier, or other action or information to be added, may be updated to reflect the processing performed for that block. Although the values ​​in each block are shown to be separate from the metadata for the file and the header data, in other embodiments, the values ​​may be based on some or all of this metadata.

[0107] Once the blockchain 770 is formed, at any point in time, an immutable chain of custody for the file can be obtained by querying the blockchain for the transaction history of values ​​across the blocks. This query, or tracking procedure, can begin by decrypting the value of the currently contained block (e.g., the last (Nth) block), and then continue decrypting values ​​of other blocks until the genesis block is reached and the original file is restored. The decryption can also include decoding the header and file at each block, as well as associated metadata.

[0108] Decryption is performed based on the type of encryption performed on each block. This may involve the use of a private key, a public key, or a public-private key pair. For example, if asymmetric encryption is used, a blockchain participant or a processor within the network may generate a public and private key pair using a predetermined algorithm. The public and private keys are related to each other through some mathematical relationship. The public key may be publicly distributed to serve as an address (e.g., an IP address or home address) for receiving messages from other users. The private key is kept secret and is used to digitally sign messages sent to other blockchain participants. The signature is included in the message so that the recipient can verify it using the sender's public key. In this way, the recipient can be sure that only the sender could have sent the message.

[0109] Generating a key pair may be similar to creating an account on the blockchain, but without actually registering anywhere. Also, every transaction performed on the blockchain is digitally signed by the sender using their private key. This signature ensures that only the account owner can track and transact (within the permissions determined by the smart contract) files on the blockchain.

[0110] 8A and 8B show additional example blockchain use cases that may be incorporated and used herein. In particular, FIG. 8A shows an example 800 of a blockchain 810 storing machine learning (artificial intelligence) data. Machine learning relies on vast amounts of past data (or training data) to build predictive models for accurate predictions on new data. Machine learning software (e.g., neural networks) can often sift through millions of records to unearth non-intuitive patterns.

[0111] 8A , host platform 820 builds and deploys machine learning models for predictive monitoring of asset 830, where host platform 820 may be a cloud platform, an industrial server, a web server, a personal computer, a user device, etc. Asset 830 can be any type of asset (e.g., machinery or equipment, etc.), such as an aircraft, a locomotive, a turbine, medical machinery and equipment, oil and gas equipment, a boat, a ship, a vehicle, etc. As another example, asset 830 may be a non-tangible asset, such as a stock, currency, digital coin, insurance, etc.

[0112] The blockchain 810 can be used to significantly improve both the machine learning model training process 802 and the prediction process 804 based on the trained machine learning model. For example, in process 802, historical data can be stored on the blockchain 810 by the asset 830 itself (or through an intermediary, not shown) without requiring a data scientist / engineer or other user to collect the data. This can significantly reduce the collection time required by the host platform 820 when performing predictive model training. For example, using smart contracts, data can be transferred directly and reliably from its origin to the blockchain 810. By using the blockchain 810 to ensure security and ownership of the collected data, the smart contract can transmit the data directly from the asset to those who use the data to build machine learning models, thereby enabling data sharing among the assets 830.

[0113] The collected data may be stored in the blockchain 810 based on a consensus mechanism that pulls together (authorized nodes) to ensure that the recorded data is verified and accurate. The recorded data is time-stamped, cryptographically signed, and immutable; therefore, it is auditable, transparent, and secure. Adding IoT devices that write directly to the blockchain can increase both the frequency and accuracy of recorded data in some cases (supply chain, healthcare, logistics, etc.).

[0114] Moreover, training the machine learning model on the collected data may require multiple rounds of refinement and testing by the host platform 820. Each round may be based on additional data or data not previously considered to help expand the machine learning model's knowledge. In process 802, the different training and testing steps (and their associated data) may be stored on the blockchain 810 by the host platform 820. Each training of the machine learning model (e.g., changes to variables, weights, etc.) may be stored on the blockchain 810. This provides verifiable proof of how the model was trained and what data was used to train the model. Moreover, when the host platform 820 finally achieves the trained model, the resulting model may be stored on the blockchain 810.

[0115] After a model is trained, it may be deployed to a live environment where predictions or decisions, or a combination thereof, can be made based on the execution of the last trained machine learning model. For example, in process 804, the machine learning model may be used for condition-based maintenance (CBM) of an asset, such as an aircraft, a wind turbine, or a healthcare machine. In this example, feedback data from the asset 830 may be input to the machine learning model and used to make event predictions, such as failure events or error codes. Decisions made by the execution of the machine learning model on the host platform 820 may be stored on the blockchain 810 to provide auditable or verifiable proof, or proof of a combination thereof. As a non-limiting example, the machine learning model may predict a future failure or malfunction, or a combination thereof, for a part of the asset 830 and generate an alert or notification to replace the part. The data behind this decision may be stored on the blockchain 810 by the host platform 820. In one embodiment, any feature or operation described or depicted or described and depicted herein, or any combination thereof, may occur on or with respect to blockchain 810.

[0116] New transactions for a blockchain can be collected together into a new block and added to the existing hash value. This is then encrypted to generate a new hash for the new block. This is added as the next list of transactions is encrypted, and so on. The result is a chain of blocks, each containing the hash values ​​of all the blocks that preceded it. Computers that store these blocks periodically compare their hash values ​​to ensure that all hash values ​​match. Any computer that disagrees discards the offending record. This approach is good for ensuring the blockchain's tamper resistance, but it's not perfect.

[0117] One way to exploit the system is for a dishonest user to alter the list of transactions to their advantage, but leave the hash unchanged. This can be done by brute force: changing the record, encrypting the result, and seeing if the hash value is the same. If not, they try again and again until they find a matching hash. The security of the blockchain is based on the belief that ordinary computers can only perform such brute force attacks on completely unrealistic timescales, such as the age of the universe. Quantum computers, by contrast, are much faster (over 1000 times faster) and pose a much greater threat.

[0118] Figure 8B shows an example 850 of a quantum-secure blockchain 852 that implements quantum key distribution (QKD) to protect against quantum computing attacks. In this example, blockchain users can verify each other's identities using QKD, which uses quantum particles, e.g., photons, to transmit information that cannot be copied by an eavesdropper without destroying the quantum particles. In this way, senders and receivers across the blockchain can confirm each other's identities.

[0119] In the example of Figure 8B, there are four users 854, 856, 858, and 860. Each pair of users may share a secret key 862 (i.e., QKD) between them. Since there are four nodes in this example, there are six pairs, and therefore, QKD AB , QKD AC , QKD AD , QKD BC , QKD BD , and QKD CD Six different secret keys 862 are used, including: 1) a key pair (QKD) and 2) a key pair (QKD) that can be used to transmit information using quantum particles, e.g., photons, creating a QKD scheme that cannot be copied by an eavesdropper without destroying the quantum particles. In this way, pairs of users can verify each other's identities.

[0120] The operation of blockchain 852 is based on two steps: (i) transaction creation and (ii) the construction of blocks that aggregate new transactions. New transactions can be created in the same way as in traditional blockchain networks. Each transaction can contain information about the sender, recipient, creation time, the amount (or value) to be transferred, a list of reference transactions that justify the sender's funds for the operation, and so on. This transaction record is then sent to all other nodes, where it is entered into a pool of unconfirmed transactions. Here, two parties (i.e., a pair of users among 854-860) authenticate the transaction by providing their distributed private key 862 (QKD). This quantum signature can be attached to every transaction, making it extremely difficult to tamper with. Each node checks its entry against its local copy of blockchain 852 and verifies that each transaction has sufficient funds. However, the transaction is not yet confirmed.

[0121] Rather than performing a traditional mining process on the block, the block may be created in a decentralized manner using a broadcast protocol. The network may apply the broadcast protocol to unconfirmed transactions at a predetermined time period (e.g., seconds, minutes, hours, etc.), thereby achieving Byzantine agreement (consensus) on the correct version of the transaction. For example, each node may possess a private value (that particular node's transaction data). In an initial round, nodes transmit their private values ​​to each other. In subsequent rounds, nodes propagate information received in previous rounds from other nodes. An honest node can then create a complete set of transactions in a new block. This new block can be added to the blockchain 852. In one embodiment, any features or operations described or depicted or described and depicted herein, or any combination thereof, may occur on or with respect to the blockchain 852.

[0122] 9 illustrates an exemplary system 900 that supports one or more of the exemplary embodiments described or depicted herein, or combinations thereof. System 900 includes a computer system / server 902 that is operable with numerous other general-purpose or special-purpose computing system environments or configurations. Examples of well-known computing systems, environments, or configurations, or combinations thereof, that may be suitable for use with computer system / server 902 include, but are not limited to, personal computer systems, server computer systems, thin clients, thick clients, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments that include any of the above-listed systems or devices.

[0123] The computer system / server 902 may be described in the general context of computer system-executable instructions, such as program modules, being executed by the computer system. Generally, program modules may include routines, programs, objects, components, logic, data structures, etc. that perform particular tasks or implement particular abstract data types.

[0124] The computer system / server 902 may also be practiced in a distributed cloud computing environment where tasks are performed by remote processing devices that are linked through a communications network. In a distributed cloud computing environment, program modules may be located in both local and remote computer system storage media, including memory storage devices.

[0125] 9, a computer system / server 902 in a cloud computing node 900 is shown in the form of a general-purpose computing device. Components of the computer system / server 902 include, but are not limited to, one or more processors or processing units 904, a system memory 906, and a bus that couples various system components comprising the system memory 906 to the processor 904.

[0126] The bus may represent any one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of the above bus structures, including various bus architectures, including, by way of example and without limitation, an Industry Standard Architecture (ISA) bus, a Micro Channel Architecture (MCA) bus, an Enhanced ISA (EISA) bus, a Video Electronics Standards Association (VESA) local bus, and a Peripheral Component Interconnect (PCI) bus.

[0127] Computer system / server 902 typically includes a variety of computer system-readable media. Such media may be any available media accessible by computer system / server 902, including both volatile and nonvolatile media, removable and non-removable media. In one embodiment, system memory 906 implements the flow diagrams of other figures.

[0128] The system memory 906 may include computer system-readable media in the form of volatile memory, such as random-access memory (RAM) 910 or cache memory 912, or a combination thereof. The computer system / server 902 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, the storage system 914 may provide for reading from and writing to non-removable, non-volatile magnetic media (not shown, typically referred to as a "hard drive"). Although not shown, a magnetic disk drive may be provided for reading from and writing to a removable, non-volatile magnetic disk (e.g., a "floppy disk"), and an optical drive may be provided for reading from or writing to a removable, non-volatile optical disk, such as a CD-ROM, DVD-ROM, or other optical media. In such cases, each may be connected to the bus by one or more data media interfaces. As further depicted and described below, memory 906 may include at least one program product having a set (e.g., at least one) of program modules configured to perform functions of various embodiments of the application.

[0129] Programs / utilities 916 having a set (at least one) of program modules 918 may be stored in memory 906, as well as, by way of example and not limitation, an operating system, one or more application programs, other program modules, and program data. Each of the operating system, one or more application programs, other program modules, and program data, or any combination thereof, may comprise an implementation of a networking environment. The program modules 918 generally perform the functions or methodologies, or combinations thereof, of various embodiments of the applications described herein.

[0130] As will be appreciated by one skilled in the art, aspects of the present invention may be embodied as a system, method, or computer program product. Accordingly, aspects of the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, microcode, etc.), or an embodiment combining software and hardware aspects, all of which may be referred to generally herein as a "circuit," "module," or "system." Furthermore, aspects of the present invention may take the form of a computer program product embodied in one or more computer-readable medium(s), the one or more computer-readable medium(s) having computer-readable program code embodied thereon.

[0131] The computer system / server 902 may also communicate with one or more external devices 920, such as a keyboard, pointing device, display 922, one or more devices that allow a user to interact with the computer system / server 902, or any device (e.g., a network card, modem, etc.) that allows the computer system / server 902 to communicate with one or more other computer devices, as well as combinations thereof. Such communication may occur via an I / O interface 924. Nevertheless, the computer system / server 902 may be connected to one or more networks, such as a local area network (LAN), a general wide area network (WAN), or a public network (e.g., the Internet), or combinations thereof, via a network adapter 926. As shown, the network adapter 926 communicates with other components of the computer system / server 902 via a bus. Although not shown, it should be understood that other hardware or software components, or combinations thereof, may be used with the computer system / server 902. Examples include, but are not limited to, microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archive storage systems.

[0132] While at least one exemplary embodiment of the system, method, and non-transitory computer-readable medium is illustrated in the accompanying drawings and described in the foregoing detailed description, it will be understood that the present invention is not limited to the disclosed embodiment(s) but is capable of numerous rearrangements, modifications, and substitutions as set forth and defined by the appended claims. For example, the functionality of the various illustrated systems may be performed by one or more of the modules or components described herein, or in a distributed architecture, and may comprise transmitters, receivers, or both. For example, all or part of the functionality performed by individual modules may be performed by one or more of these modules. Furthermore, the functionality described herein may be performed at various times and in conjunction with various events, internal or external to the modules or components. Furthermore, information transmitted between various modules may be transmitted between modules via at least one of a data network, the Internet, a voice network, an Internet Protocol network, a wireless device, a wired device, or multiple protocols, or a combination thereof. Furthermore, messages sent or received by any module may be transmitted, received, or transmitted / received directly, via one or more other modules, or a combination thereof.

[0133] Those skilled in the art will understand that a "system" can be embodied as a personal computer, a server, a console, a personal digital assistant (PDA), a mobile phone, a tablet computing device, a smartphone, or any other suitable computing device, or a combination of these devices. Presenting the above-described functions as being performed by a "system" is not intended to limit the scope of the present invention in any way, but rather to provide one example of many possible implementations. Indeed, the methods, systems, and devices disclosed herein can be implemented in localized and distributed configurations consistent with computing technology.

[0134] It should be noted that some of the features of the systems described herein are presented as modules to more particularly emphasize their implementation independence. For example, a module may be implemented as a hardware circuit comprising custom very large-scale integration (VLSI) circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. A module may also be implemented within programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices, or graphics processing units.

[0135] Modules may also be implemented, at least partially, in software for execution by various types of processors. An identified unit of executable code may comprise one or more physical or logical blocks of computer instructions, which may be organized, for example, as an object, procedure, or function. Nevertheless, the executable code of an identified module need not be physically located together and may comprise heterogeneous instructions stored in different locations, which, when logically combined, may comprise a module and achieve the purpose stated above for the module. Furthermore, a module may be stored on a computer-readable medium, such as a hard disk drive, a flash device, a random access memory (RAM), a tape, or any other such medium used to store data.

[0136] In fact, a module of executable code may be a single instruction, or many instructions, and may be distributed among several different code segments, different programs, and across several memory devices. Similarly, operational data may be identified and illustrated herein in modules and may be embodied in any suitable form and organized within any suitable type of data structure. The operational data may be collected as a single data set or may be distributed in different locations, including on different storage devices, or may exist, at least in part, simply as electronic signals on a system or network.

[0137] It will be readily understood that the components of the present invention, as generally described and illustrated in the Figures herein, could be arranged and designed in a wide variety of different configurations. Thus, the detailed description of the embodiments is not intended to limit the scope of the present invention as claimed, but is merely representative of selected embodiments of the present invention.

[0138] Those skilled in the art will readily appreciate that the above may be implemented with the hardware elements in a different order than that described above and / or in a different configuration than that disclosed. Thus, while the present invention has been described based on these preferred embodiments, certain modifications, variations, and alternative constructions will be apparent to those skilled in the art.

[0139] While preferred embodiments of the present invention have been described, it will be understood that the described embodiments are by way of example only, and that the scope of the present invention is defined solely by the appended claims when considered along with the full range of equivalents and modifications thereto (e.g., protocols, hardware devices, software platforms, etc.).

Claims

1. 1. An apparatus comprising: a processor configured to divide a session key into a plurality of partial shares, distribute the plurality of partial shares to a plurality of content providers, and encrypt a stream of media content based on the session key, wherein each content provider receives a different partial share of the session key; and a network interface configured to transmit the encrypted stream of digital content to a user device having one or more fractional shares of the plurality of fractional shares; It is equipped with the processor is configured to control the network interface to simultaneously transmit the encrypted stream of digital content from a host platform to multiple user devices over a computing network. Device.

2. 1. An apparatus comprising: a processor configured to divide a session key into a plurality of partial shares, distribute the plurality of partial shares to a plurality of content providers, and encrypt a stream of media content based on the session key, wherein each content provider receives a different partial share of the session key; and a network interface configured to transmit the encrypted stream of digital content to a user device having one or more fractional shares of the plurality of fractional shares; It is equipped with the network interface is further configured to receive, via a blockchain, a list of registered user devices that are registered with the stream of digital content, and broadcast the encrypted stream of digital content to the list of registered user devices received from the blockchain. Device.

3. 3. The apparatus of claim 1, wherein the processor is configured to divide a session into the plurality of partial shares via a threshold encryption scheme in which a threshold number of partial shares are required to reconstruct the session key.

4. 3. The apparatus of claim 1, wherein the processor is configured to divide the session key into a number of fractional shares equal to the number of content providers.

5. 3. The apparatus of claim 2, wherein the processor is configured to control the network interface to simultaneously transmit the encrypted stream of digital content from a host platform to multiple user devices over a computing network.

6. 3. The apparatus of claim 1, wherein the session key is recoverable from a predefined number of partial shares, and wherein the predefined number of partial shares is greater than two partial shares and less than all of the plurality of partial shares.

7. 10. The apparatus of claim 1, wherein the network interface is further configured to receive, via a blockchain, a list of registered user devices that are registered with the stream of digital content, and to broadcast the encrypted stream of digital content to the list of registered user devices received from the blockchain.

8. 10. The apparatus of claim 2 or 7, wherein the blockchain includes a plurality of blockchain peers, and each blockchain peer serves a different respective subset of a plurality of registered user devices.

9. 3. The apparatus of claim 1, wherein the single session key includes a private key of a symmetric key pair that is split into the plurality of partial shares, and the processor is configured to encrypt the stream of digital content via a public key of the symmetric key pair.

10. Splitting a session key into multiple partial shares; distributing the plurality of fractional shares to a plurality of content providers, respectively, wherein each content provider receives a different fractional share of the session key; encrypting a stream of media content based on the session key; and transmitting the encrypted stream of digital content to a user device having one or more partial shares of the plurality of partial shares; Including, said transmitting includes transmitting the encrypted stream of digital content from a host platform to multiple user devices simultaneously over a computing network. method.

11. A method, comprising: Splitting a session key into multiple partial shares; distributing the plurality of fractional shares to a plurality of content providers, respectively, wherein each content provider receives a different fractional share of the session key; encrypting a stream of media content based on the session key; and transmitting the encrypted stream of digital content to a user device having one or more partial shares of the plurality of partial shares; Including, The method further includes receiving, via a blockchain, a list of registered user devices that are registered with the stream of digital content, and the transmitting includes broadcasting the encrypted stream of digital content to the list of registered user devices received from the blockchain. The method.

12. 12. The method of claim 10 or 11, wherein the dividing comprises dividing the session into the plurality of partial shares via a threshold encryption scheme, where a threshold number of partial shares are required to reconstruct the session key.

13. 12. The method of claim 10 or 11, wherein said dividing comprises dividing the session key into a number of partial shares equal to the number of content providers.

14. 12. The method of claim 11, wherein said transmitting comprises transmitting the encrypted stream of digital content from a host platform to multiple user devices simultaneously over a computing network.

15. 12. The method of claim 10 or 11, wherein the session key is recoverable from a predefined number of partial shares, and wherein the predefined number of partial shares is greater than two partial shares and less than all of the plurality of partial shares.

16. 11. The method of claim 10, further comprising receiving, via a blockchain, a list of registered user devices that are registered with the stream of digital content, and wherein transmitting comprises broadcasting the encrypted stream of digital content to the list of registered user devices received from the blockchain.

17. 17. The method of claim 16, wherein the blockchain includes a plurality of blockchain peers, and each blockchain peer serves a different respective subset of a plurality of registered user devices.

18. 12. The method of claim 10 or 11, wherein the one session key includes a private key of a symmetric key pair that is divided into the plurality of partial shares, and wherein the encrypting includes encrypting the stream of digital content using a public key of the symmetric key pair.

19. A computer program causing one or more processors to carry out the steps of the method according to claim 10 or 11.

Images