Threshold encryption of broadcast content

Abstract

An example operation may include: splitting a session key into multiple partial shares, distributing the multiple partial shares to multiple content providers, wherein each content provider receives a different partial share of the session key, encrypting a media content stream based on the session key, and sending the encrypted digital content stream to a user device, wherein the user device has one or more partial shares among the multiple partial shares.

Description

Background Technology

[0001] A centralized platform stores and maintains data in a single location. This location is typically a central computer, such as a cloud computing environment, web server, or mainframe computer. Information stored on a centralized platform is usually accessible from multiple different points. Multiple users or client workstations can work simultaneously on the centralized platform, for example, based on a client / server configuration. Centralized platforms are easy to manage, maintain, and control due to their single location, especially for security purposes. Within a centralized platform, data redundancy is minimized because the single storage location of all data also implies that a given dataset has only one master record. Summary of the Invention

[0002] One example embodiment provides an apparatus including: a processor configured to perform one or more of the following operations: splitting a session key into multiple partial shares, distributing the multiple partial shares to multiple content providers, wherein each content provider receives a different partial share of the session key, and encrypting a media content stream based on the session key; and a network interface configured to send an encrypted digital content stream to a user equipment having one or more of the multiple partial shares.

[0003] Another example embodiment provides a method comprising: splitting a session key into multiple partial shares, distributing the multiple partial shares to multiple content providers, wherein each content provider receives a different partial share of the session key; encrypting a media content stream based on the session key; and sending an encrypted digital content stream to a user equipment having one or more of the multiple partial shares.

[0004] Another example embodiment provides a non-transitory computer-readable medium including instructions that, when read by a processor, cause the processor to perform one or more of the following operations: splitting a session key into multiple partial shares; distributing the multiple partial shares to multiple content providers, wherein each content provider receives a different partial share of the session key; encrypting a media content stream based on the session key; and sending an encrypted digital content stream to a user equipment having one or more of the multiple partial shares. Attached Figure Description

[0005] Figure 1 This is a diagram illustrating a computing environment for broadcast encryption according to an example embodiment.

[0006] Figure 2A This is a diagram illustrating an example blockchain architecture configuration according to an example embodiment.

[0007] Figure 2B This is a diagram illustrating the blockchain transaction flow between nodes according to an example embodiment.

[0008] Figure 3A This is a diagram illustrating a licensed network according to an example embodiment.

[0009] Figure 3B This is a diagram illustrating another licensed network according to an example embodiment.

[0010] Figure 3C This is a diagram illustrating an unlicensed network according to an example embodiment.

[0011] Figure 4A This is a diagram illustrating the process of distributing a share of the session key according to an example embodiment.

[0012] Figure 4B This is a diagram illustrating the processing of session key-based broadcast content according to an example embodiment.

[0013] Figure 4C This is a diagram illustrating another process of distributing a share of the session key according to another example embodiment.

[0014] Figure 4D This is a diagram illustrating another process of broadcasting content based on a session key according to an example embodiment.

[0015] Figure 5 This is a diagram illustrating a method for broadcast encryption according to an example embodiment.

[0016] Figure 6A This is a diagram illustrating an example system configured to perform one or more operations described herein, according to an example embodiment.

[0017] Figure 6B This is a diagram illustrating another example system configured to perform one or more operations described herein, according to an example embodiment.

[0018] Figure 6C This is a diagram illustrating another example system configured to utilize smart contracts according to an example embodiment.

[0019] Figure 6D This is a diagram illustrating yet another example system configured to utilize blockchain according to an example embodiment.

[0020] Figure 7A This is a diagram illustrating the process of adding a new block to a distributed ledger according to an example embodiment.

[0021] Figure 7B This is a diagram illustrating the data content of a new data block according to an example embodiment.

[0022] Figure 7C This is a diagram illustrating a blockchain for digital content according to an example embodiment.

[0023] Figure 7D This is a diagram illustrating a block that can represent the block structure in a blockchain according to an exemplary embodiment.

[0024] Figure 8A This is a diagram illustrating an example blockchain for storing machine learning (artificial intelligence) data according to an example embodiment.

[0025] Figure 8B This is a diagram illustrating an example quantum-safe blockchain according to an example embodiment.

[0026] Figure 9 This is a diagram illustrating an example system that supports one or more example embodiments. Specific Implementation

[0027] It will be readily understood that, as generally described and illustrated in the accompanying drawings, the components of the present invention can be arranged and designed in a variety of different configurations. Therefore, the following detailed description of at least one embodiment of the methods, apparatus, non-transitory computer-readable media, and systems illustrated in the drawings is not intended to limit the scope of the claimed applications, but is merely representative of selected embodiments.

[0028] In one or more embodiments, the features, structures, or characteristics described throughout this specification may be combined or removed in any suitable manner. For example, the phrases “example embodiment,” “some embodiments,” or other similar language used throughout this specification refer to the fact that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment. Therefore, the phrases “example embodiment,” “some embodiments,” “in other embodiments,” or other similar language appearing throughout this specification do not necessarily all refer to the same set of embodiments, and the described features, structures, or characteristics may be combined or removed in any suitable manner in one or more embodiments. Furthermore, in the figures, any connection between elements may allow unidirectional and / or bidirectional communication, even if the depicted connection is a unidirectional or bidirectional arrow. Moreover, any device depicted in the figures may be a different device. For example, if a mobile device is shown as transmitting information, a wired device may also be used to transmit information.

[0029] Furthermore, although the term "message" may have been used in the description of the embodiments, this application can be applied to many types of networks and data. Additionally, while certain types of connections, messages, and signaling may be described in the exemplary embodiments, this application is not limited to certain types of connections, messages, and signaling.

[0030] The example embodiments provide methods, systems, components, non-transitory computer-readable media, devices, and / or networks for a broadcast encryption system based on threshold encryption. In the example embodiments, digital content protected by digital rights management (DRM) rules can be encrypted and then broadcast to multiple consumer devices.

[0031] 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 the other key (e.g., a private key) is used for decryption. Example embodiments use threshold encryption to divide or split the session key (e.g., the key used to decrypt encrypted content) into multiple secrets or partial shares, instead of using a single decryption key. Because the system uses threshold encryption, the session key can be recovered using a predetermined number of partial shares (e.g., a majority share, etc.) without requiring all partial shares.

[0032] A partial share can be distributed to multiple content providers, allowing each provider to receive a unique partial share of its own session key. Content providers can include organizations that generate content in digital form (e.g., music, movies, software, etc.). Each content provider can register its own set of users / user devices for downloading and playing the corresponding content segments. During the registration process, content providers can offer partial shares to user devices for storage. User devices can register with most or all content providers to obtain sufficient partial shares to reconstruct the session key and decrypt the content.

[0033] Each content provider can store its list of registered users on a blockchain. Here, content providers can also be participants in the blockchain (blockchain peers). Through the blockchain, each content provider can track the lists of registered users of all other content providers. Furthermore, each content provider can provide its own list of registered users to broadcasting platforms, such as streaming services.

[0034] A broadcasting device can group users from a list of registered users together and broadcast the content to the group. For a user device to decrypt the content, it must have a sufficient fractional share to reconstruct the session key and decrypt the encrypted content based on the reconstructed session key. However, if the user device does not have a sufficient fractional share, it will not be able to recover the session key and decrypt the content.

[0035] The example implementation improves upon existing broadcast encryption systems by using threshold encryption to split the encryption / decryption scheme. For example, an unauthorized user might gain access to a content provider (and its corresponding partial share). Here, the unauthorized user could be a hacker or other malicious actor. However, gaining access to the content provider and its corresponding partial share would be insufficient for the unauthorized user to decrypt the broadcast content, as the user would only have one partial share, not the threshold number required to reconstruct the session key and decrypt the content. As another example, a malicious actor could transfer partial shares from a content provider intended for a registered user. In this case, the registered user might not receive a partial share. However, if the registered user has sufficient partial shares from other content providers, they will still be able to recover the session key.

[0036] In one embodiment, the application utilizes a decentralized database (such as a blockchain) as a distributed storage system, comprising multiple nodes that communicate with each other. The decentralized database comprises an append-only, immutable data structure, similar to a distributed ledger capable of maintaining records between mutually distrustful parties. These distrustful parties are referred to herein as peers or peer nodes. Each peer maintains a copy of the database records, and no single peer can modify a database record without consensus among the distributed peers. For example, peers can execute a consensus protocol to verify blockchain storage transactions, group storage transactions into blocks, and build a hash chain on the blocks. This process forms the ledger by ordering the storage transactions, which is necessary for consistency. In various implementations, permissioned and / or permissionless blockchains can be used. In public or permissionless blockchains, anyone can participate without a specific identity. Public blockchains may involve native cryptocurrencies and utilize consensus based on various protocols such as Proof-of-Work (PoW). On the other hand, permissioned blockchain databases provide secure interaction between a group of entities sharing common goals but not fully trusting each other, such as commerce involving the exchange of funds, goods, information, etc.

[0037] This application can utilize blockchains that operate on arbitrary, programmable logic, customized as a decentralized storage scheme and referred to as "smart contracts" or "chaincode." In some cases, there may be dedicated chaincode, referred to as system chaincode, used for managing functions and parameters. Applications can also utilize smart contracts as trusted distributed applications, leveraging the tamper-proof nature of the blockchain database and underlying agreements between nodes, known as endorsement or endorsement policies. Blockchain transactions associated with this application can be "endorsed" before being submitted to the blockchain, while unendorsed transactions are ignored. Endorsement policies allow chaincode to specify the endorsers of a transaction in the form of a set of peer nodes necessary for endorsement. When a client sends a transaction to the peers specified in the endorsement policy, the transaction is executed to verify it. After verification, the transactions enter a sorting phase, where a consensus protocol is used to generate an ordered sequence of endorsed transactions that are divided into blocks.

[0038] This application can utilize nodes as communication entities in a blockchain system. The ability of a "node" to perform logical functions means that different types of nodes can run on the same physical server. Nodes are grouped in trust domains and associated with logical entities that control them in various ways. Nodes can include different types, such as client or submitting client nodes that submit transaction calls to endorsers (e.g., peers) and broadcast transaction protocols to ordering services (e.g., ordering nodes). Another type of node is a peer node that receives transactions submitted by clients, submits transactions, and maintains the state and copies of the ledger of blockchain transactions. Peers can also have the role of endorsers, although this is not required. Ordering service nodes, or orderers, are nodes that run communication services for all nodes and implement delivery guarantees, such as broadcasting to every peer in the system when a transaction is submitted and the state of the blockchain world is modified. This is another name for the initial blockchain transaction, which typically includes control and setup information.

[0039] This application can utilize a ledger, which is an ordered, tamper-proof record of all state transitions in a blockchain. State transitions can be generated by chaincode calls (i.e., transactions) submitted by participants (e.g., client nodes, ordering nodes, endorser nodes, peer nodes, etc.). Each participant (such as a peer node) can maintain a copy of the ledger. A transaction can result in a set of asset key-value pairs being submitted to the ledger as one or more operands, such as create, update, delete, etc. The ledger includes a blockchain (also called a chain) for storing tamper-proof, ordered records in blocks. The ledger also includes a state database that maintains the current state of the blockchain.

[0040] This application can utilize a chain as a transaction log, constructed as hash-linked blocks, with each block containing a sequence of N transactions, where N is equal to or greater than one. The block header includes the hashes of the block's transactions and the hashes of the headers of previous blocks. In this way, all transactions on the ledger can be ordered and cryptographically linked together. Therefore, it is impossible to tamper with the ledger data without breaking the hash linking. The hash of the most recently added blockchain block represents every transaction on the chain that came before it, ensuring that all peer nodes are in a consistent and trusted state. This chain can be stored on a peer-to-peer file system (i.e., local, attached storage, cloud, etc.), thus efficiently supporting the attached-only nature of blockchain workloads.

[0041] The current state of the immutable ledger represents the latest value of all keys included in the chain's transaction log. Because the current state represents the most recent key value known to the channel, it is sometimes referred to as the world state. Chaincode calls execute transactions against the ledger's current state data. To make these chaincode interactions effective, the latest value of the key can be stored in a state database. The state database can simply be an indexed view of the chain's transaction log and therefore can be regenerated from the chain at any time. The state database can be automatically restored (or generated if needed) when peer nodes start up and before accepting transactions.

[0042] Broadcast encryption is the process of delivering encrypted content (e.g., TV programs, DVDs, Blu-rays, MP3s, etc.) over a broadcast channel in a manner that allows only registered users (e.g., subscribers) to decrypt the content. Instead of directly encrypting the content for each user, broadcast encryption schemes distribute key information that allows registered users to reconstruct the encryption (or decryption) key and decrypt the content, while revoked users or otherwise unauthorized users do not have sufficient information to recover the key. The difficulty of broadcast encryption lies in ensuring that only registered users can decrypt broadcast content.

[0043] In the example implementation, each content provider is responsible for maintaining a list of registered users. This list may be stored on a blockchain. However, a portion controlled by the content provider (e.g., split session keys) is not stored on the blockchain but is kept secret from the content provider.

[0044] Figure 1 A computing environment 100 for broadcast encryption according to an example embodiment is shown. (Refer to...) Figure 1The broadcast encryption system (i.e., broadcast device 120) is configured to broadcast content to multiple user devices 131-134 via a channel such as the Internet or a network connection. In this example, broadcast device 120 may be a central host system that sends content to user devices 131-134, such as a streaming platform, cloud computing environment, web server, database, etc. Meanwhile, each corresponding user device 131-134 may be a computing system, television, vehicle, appliance, etc., capable of playing media, multimedia, digital content, such as audio, video, documents, files, software programs, etc.

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

[0046] Before broadcasting content to user devices 131-134, broadcasting device 120 can encrypt the content 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 encrypt and decrypt digital content. In this example, the session key may be split into 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 including a private key and a public key. The private key may be split into shares and distributed to content providers 111-113 so that each content provider receives a different share of the secret. Here, broadcasting device 120 can use the public key to encrypt the content and can use the private key to decrypt the encrypted content.

[0047] For example, a session key can be split into N partial shares. In some embodiments, K may correspond to the number of content providers participating in the system. Each content provider will receive a unique partial share. To reconstruct the session key, a user must obtain at least K partial shares, where K is less than N; for example, N could be equal to 10, and K could be equal to 6. Here, each user must obtain at least 6 / 10 of the shares before they can recover the session key and decrypt the broadcast content. Meanwhile, if a user obtains fewer than K partial shares, the user will not be able to recover the session key. Therefore, if a user obtains only 5 partial shares or less, the user will not be able to decrypt the broadcast content.

[0048] Examples of threshold encryption schemes include, but are not limited to, Shamir's secret share.

[0049] Before user equipment 131 (or any user equipment 131-134) can decrypt broadcast content downloaded from broadcast device 120, user equipment 131 must obtain a sufficient partial share of the session key from enough content providers 111-113 to satisfy the threshold encryption scheme. In other words, user equipment 131 must obtain a sufficient partial share of the session key to recover the session key and ultimately use the recovered session key to decrypt the broadcast content. As a non-limiting example, the threshold can be a large portion of the partial share, but the embodiment is not limited to this. The threshold can be any desired number. In this example, there are three content providers 111-113. As an example, user equipment 131 may need at least two of the three partial shares to reconstruct the session key.

[0050] According to various embodiments, content providers 111-113 may implement a blockchain network among themselves, where each content provider 111-113 is a blockchain peer maintaining a copy of blockchain 110 (e.g., a distributed blockchain ledger). Content providers 111-113 may store their user lists on blockchain 110. In some embodiments, the lists may include subsets of user devices that are different from other user devices; however, multiple overlapping users may exist. User devices 131-134 wish to register with as many content providers 111-113 as possible. Therefore, each list may be referred to as a subset of registered users broadcasting content. Registered users are considered authorized to consume and decrypt 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). Furthermore, the lists may be updated over time, for example, by adding new users, deleting users, etc.

[0051] See below for reference. Figure 4A Further described, each user device 131-134 may pre-register with one or more content providers 111-113. During the registration process, user devices 131-134 will receive a partial share of a session key (i.e., a corresponding partial share from each content provider to which they are registered). Thus, each user device 131-134 will receive a subset of the partial shares. In some cases, the subset may include all partial shares, but this is not always the case.

[0052] In order for user equipment 131 (or any user equipment 131-134) to decrypt broadcast content received from broadcast device 120, user equipment 131 must have a sufficient partial share of the session key to recover the session key according to the threshold encryption scheme. Once the session key is recovered, user equipment 131 can decrypt and play or otherwise consume the content.

[0053] Broadcasting device 120 can receive corresponding lists (list A, list B, and list C) from content providers 111-113 at periodic or continuous intervals. Each list can be dedicated to specific content that is continuously updated based on new users, invalidated users, etc. The list can include identification information for each user device, such as IP address, device ID, username, email, user address, phone number, etc. Broadcasting device 120 can identify all unique user devices that have registered to use the content from the lists provided by content provider 111 (e.g., by IP address, device ID, username, email, phone number, etc.). The broadcasting device can identify all users from all the set lists and send a broadcast signal containing the content stored therein to all identified users. For example, if a user device is listed on only one of the three lists, broadcasting device 120 will still broadcast a signal including encrypted content. However, only user devices 131-134 that have obtained a sufficient portion of the session key can recover the session key and decrypt the encrypted content.

[0054] Figure 2A A blockchain structure configuration 200 according to an example embodiment is shown. (Reference) Figure 2A The blockchain architecture 200 may include certain blockchain elements, such as a set of blockchain nodes 202. Blockchain nodes 202 may include one or more nodes 204-210 (these four nodes are described as examples only). These nodes participate in multiple activities, such as blockchain transaction increment and verification processes (consistency). One or more of the blockchain nodes 204-210 may endorse transactions based on an endorsement policy and may provide ordering services for all blockchain nodes in the architecture 200. A blockchain node may initiate blockchain authorization and seek to write to the blockchain's immutable ledger stored in blockchain layer 216, a copy of which may also be stored on the underlying physical infrastructure 214. The blockchain configuration may include 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 may be created according to a customized configuration sought by the participants and may maintain its own state, control its own assets, and receive external information. This can be deployed as transactions and installed on all blockchain nodes 204-210 via attachment to the distributed ledger.

[0055] The blockchain infrastructure or platform 212 may include layers of blockchain data and services (e.g., cryptographic trust services, virtual execution environments, etc.), and supports physical computer infrastructure that can be used to receive and store new transactions and provide access to authorized agencies attempting to access data entries. The blockchain layer 216 may expose interfaces that provide access to the processor code and the virtual execution environment necessary for participation in the physical infrastructure 214. The cryptographic trust service 218 can be used to verify transactions such as asset exchange transactions and maintain information privacy.

[0056] Figure 2A The blockchain architecture configuration can process and execute program / application code 220 via one or more interfaces exposed by the blockchain platform 212 and the services provided. Code 220 can control blockchain assets. For example, code 220 can store and transmit data and can be executed by nodes 204-210, conforming to its execution in the form of smart contracts and associated chaincode with conditional or other code elements. As a non-limiting example, smart contracts can be created to execute alerts, updates, and / or conform to other notifications of changes, updates, etc. Smart contracts themselves are used to authorize and access requirements associated with the ledger and usage rules. For example, a smart contract (or chaincode that executes the logic of a smart contract) can read blockchain data 226, which can be processed by one or more processing entities (e.g., virtual machines) included in the blockchain layer 216 to generate results 228 including alerts, liability determination, etc., within complex service scenarios. Physical infrastructure 214 can be used to retrieve any data or information described herein.

[0057] Smart contracts can be created using high-level applications and programming languages ​​and then written into blocks in a blockchain. Smart contracts may include executable code that is registered, stored, and / or replicated to the blockchain (e.g., a distributed network of blockchain peers). A transaction is the execution of smart contract logic, which can be executed in response to the fulfillment of conditions associated with the smart contract. Execution of a smart contract can trigger one or more trusted modifications to the state of the digital blockchain ledger. Modifications to the blockchain ledger caused by smart contract execution can be automatically replicated throughout the distributed network of blockchain peers via one or more consensus protocols.

[0058] Smart contracts can write data to the blockchain in key-value pair format. Furthermore, smart contract code can read values ​​stored in the blockchain and use them in application operations. Smart contract code can write the output of various logical operations to one or more blocks within the blockchain. This code can be used to create temporary data structures in virtual machines or other computing platforms. Data written to the blockchain can be public and / or can be encrypted and maintained as private. Temporary data used / generated by the smart contract is held in memory by the provided execution environment and then deleted once the data required by the blockchain is identified.

[0059] Chaincode can include a code interpretation (e.g., logic) of a smart contract. For example, chaincode can include an encapsulation and deployable version of logic within a smart contract. As described herein, chaincode can be program code deployed on a computing network, where it is executed and verified together by a chain of validators during the consensus process. Chaincode can receive hashes and retrieve hashes from the blockchain associated with a data template created using a previously stored feature extractor. If the hash of the hash identifier matches a hash created from the stored identifier template data, the chaincode sends an authorization key to the requested service. Chaincode can write data associated with cryptographic details to the blockchain.

[0060] Figure 2B An example of a blockchain transaction flow 250 between nodes of a blockchain according to an example embodiment is shown. (Reference) Figure 2B The transaction flow may include client node 260 sending transaction protocol 291 to endorsing peer node 281. Endorsing peer 281 may verify the client's signature and execute chaincode functions to initiate the transaction. Output may include the chaincode result, a set of key / value versions read from the chaincode (read set), and a set of key / value versions written to the chaincode (write set). Here, endorsing peer 281 may determine whether to endorse the transaction protocol. If approved, a proposal response 292 is sent back to client 260 along with the endorsement signature. Client 260 assembles the endorsement into the transaction payload 293 and broadcasts it to the ordering service node 284. The ordering service node 284 then delivers the ordered transactions as blocks on the channel to all peers 281-283. Before being committed to the blockchain, each peer 281-283 may verify the transaction. For example, a peer may check the endorsement policy to ensure that the correct allocation of the designated peer has signed the result and verified the signature 293 against the transaction payload.

[0061] Refer again Figure 2BThe client node initiates transaction 291 by constructing a request and sending it to peer node 281, which acts as the endorser. Client 260 may include an application utilizing a supporting Software Development Kit (SDK) that leverages available APIs to generate a transaction protocol. This protocol requests chaincode functions to read and / or write data to the ledger (i.e., write new key-value pairs for assets). The SDK can be used as a patch to package the transaction protocol into an appropriate architectural format (e.g., a protocol buffer over a Remote Procedure Call (RPC)) and uses the client's cryptographic certificate to generate a unique signature for the transaction protocol.

[0062] In response, endorsing peer 281 can verify that (a) the transaction protocol is intact, (b) the past transaction has not been committed (replay attack protection), (c) the signature is valid, and (d) the submitter (client 260 in this example) is correctly authorized to perform the suggested operation on the channel. Endorsing peer 281 can take the transaction protocol input as arguments to the invoked chaincode function. The chaincode is then executed against the current state database to produce a transaction result including response values, a set of reads, and a set of writes. However, the ledger is not updated at this time. At 292, this set of values, along with the signature of endorsing peer 281, is passed back to client 260's SDK as protocol response 292, which parses the payload to be consumed by the application.

[0063] In response, the application on client 260 checks / verifies the signature of the endorsing peer and compares the protocol response to determine if they are identical. If the chaincode only queries the ledger, the application will check the query response and typically will not submit the transaction to the ordering node service 284. If the client application wants to submit the transaction to the ordering node service 284 to update the ledger, the application determines whether the specified endorsement policy has been satisfied before submission (i.e., whether all peers required for the transaction have endorsed it). Here, the client may include only one of the multiple parties to the transaction. In this case, each client may have its own endorser node, and each endorser node will be required to endorse the transaction. This architecture ensures that even if the application chooses not to check the response or otherwise forwards unendorsed transactions, the endorsement policy will still be enforced by the peers and supported during the submission confirmation phase.

[0064] After a successful check, in step 293, client 260 assembles the endorsement into the transaction protocol and broadcasts the transaction protocol and response to sorting node 284 within the transaction message. A transaction may contain a read / write set, endorsement peer signatures, and a channel ID. Sorting node 284 does not need to examine the entire contents of a transaction to execute its operation; instead, it can simply receive transactions from all channels in the network, sort them by channel in chronological order, and create transaction blocks by channel.

[0065] These blocks are delivered on the channel from sorting node 284 to all peer nodes 281-283. The data portions within the blocks can be verified to ensure the endorsement policy is met and to ensure that there have been no changes to the ledger state of the read set variables since the read set was generated by transaction execution. Furthermore, in step 295, each peer node 281-293 appends a block to the channel chain, and for each valid transaction, a write set can be committed to the current state set. Events can be emitted to notify clients that the application transaction (call) has been immutably appended to the chain, and to notify whether the transaction is valid or invalid.

[0066] Figure 3A An example of a permissioned blockchain network 300 is shown, characterized by a distributed, decentralized peer-to-peer architecture. In this example, blockchain user 302 can initiate transactions to a permissioned blockchain 304. In this example, transactions can be deployments, invocations, or queries, and can be issued via client-side applications utilizing the SDK, directly through APIs, etc. The network can provide access to regulators 306, such as auditors. Blockchain network operator 308 manages member permissions, such as registering regulator 306 as an "auditor" and blockchain user 302 as a "client." Auditors can be restricted to querying only the ledger, while clients can be authorized to deploy, invoke, and query certain types of chaincode.

[0067] Blockchain developer 310 can write chaincode and client applications. Blockchain developer 310 can directly deploy chaincode to the network via an interface. To include credentials from traditional data source 312 in the chaincode, developer 310 can use out-of-band connections to access the data. In this example, blockchain user 302 connects to the permissioned blockchain 304 via peer node 314. Before any transaction is made, peer node 314 retrieves the user's registration and transaction certificates from the Certificate Authority 316, which manages user roles and permissions. In some cases, blockchain users must possess these digital certificates to transact on the permissioned blockchain 304. Simultaneously, users attempting to utilize the chaincode may need to verify their credentials on the traditional data source 312. To confirm user authorization, the chaincode can use an out-of-band connection to this data via a traditional processing platform 318.

[0068] Figure 3B Another example of a permissioned blockchain network 320 is shown, characterized by a distributed, decentralized peer-to-peer architecture. In this example, blockchain user 322 can submit transactions to a permissioned blockchain 324. In this example, transactions can be deployments, invocations, or queries, and can be issued via client-side applications utilizing the SDK, directly through APIs, etc. The network can provide access to regulators 326, such as auditors. Blockchain network operator 328 manages member permissions, such as registering regulator 326 as "auditors" and blockchain user 322 as "clients." Auditors can be restricted to querying only the ledger, while clients can be authorized to deploy, invoke, and query certain types of chaincode.

[0069] Blockchain developer 330 writes chaincode and client applications. Blockchain developer 330 can deploy the chaincode directly to the network via an interface. To include credentials from traditional data source 332 in the chaincode, developer 330 can use an out-of-band connection to access the data. In this example, blockchain user 322 connects to the network through peer node 334. Before any transaction is made, peer node 334 retrieves the user's registration and transaction certificates from certificate authority 336. In some cases, blockchain users must possess these digital certificates to transact on the permissioned blockchain 324. Simultaneously, users attempting to use the chaincode may need to verify their certificates on traditional data source 332. To confirm user authorization, the chaincode can use an out-of-band connection to this data through a traditional processing platform 338.

[0070] In some implementations, the blockchain described herein can be a permissionless blockchain. In contrast to a permissioned blockchain that requires permission to join, anyone can join a permissionless blockchain. For example, to join a permissionless blockchain, a user can create a personal address and begin interacting with the network by submitting transactions, thus adding entries to the ledger. Additionally, all parties can choose to run nodes on the system and employ mining protocols to help verify transactions.

[0071] Figure 3CThe process 350 of a transaction processed by a permissionless blockchain 352 comprising multiple nodes 354 is illustrated. A sender 356 intends to send payment or some other form of value (e.g., contract, medical record, agreement, goods, services, or any other asset that can be encapsulated in a digital record) to a receiver 358 via the permissionless blockchain 352. In one embodiment, each of the sender device 356 and the receiver device 358 may have a digital wallet (associated with the blockchain 352) that provides user interface control and displays transaction parameters. In response, the transaction is broadcast to nodes 354 throughout the blockchain 352. Depending on the network parameters of the blockchain 352, the nodes verify the transaction 360 based on rules established by the creator of the permissionless blockchain 352 (which may be predefined or dynamically assigned). For example, this may include verifying the identities of the parties involved. The transaction may be verified immediately, or it may be queued along with other transactions, and the nodes 354 may determine whether the transaction is valid based on a set of network rules.

[0072] In structure 362, valid transactions are formed into blocks and sealed with a lock (hash). This process can be performed by nodes in mining nodes 354. Mining nodes can utilize additional software specifically designed for mining and creating blocks on the permissionless blockchain 352. Each block can 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 set of valid transactions.

[0073] References to the hash of the previous block are associated with the creation of a secure, independent blockchain.

[0074] Before blocks can be added to the blockchain, they must be verified. Verification of permissionless blockchains (352) may include proof-of-work (PoW) as a solution to a puzzle derived from the header of a block. Although in Figure 3C Not shown in the example, but another process used to verify blocks is proof-of-stake. Unlike proof-of-work, where the algorithm rewards miners who solve mathematical problems, proof-of-stake uses a deterministic method to select the creator of a new block based on their wealth, also defined as "stake." A similar proof is then performed by the selected / picked node.

[0075] By mining 364 blocks, nodes attempt to solve the block by incrementally changing a variable until the solution satisfies the network-wide objective. This creates Proof-of-Work (PoW), ensuring correct responses. In other words, a potential solution must prove that computational resources are exhausted while solving the problem. In some types of permissionless blockchains, miners can be rewarded with value (e.g., coins) for correctly mining blocks.

[0076] Here, in addition to the blockchain itself, the Proof-of-Work (PoW) process makes modifying the blockchain extremely difficult because an attacker must modify all subsequent blocks to accept a change in one block. Furthermore, as new blocks are mined, the difficulty of modifying a block increases, and the number of subsequent blocks also increases. Successfully verified blocks are distributed via distribution 366 through the permissionless blockchain 352, and all nodes 354 add the block to the majority chain, which is the auditable ledger of the permissionless blockchain 352. Additionally, the value in a transaction submitted by the sender 356 is stored or otherwise transferred to the digital wallet of the recipient device 358.

[0077] Figure 4A The process 400A for distributing a share of the session key according to an example embodiment is illustrated. Figure 4B A process 400B based on a session key for broadcasting content is illustrated according to an example embodiment. (Reference) Figure 4A The broadcasting device 410 splits the session key 420 into multiple partial shares 420A, 420B, 420C, and 420D, respectively, corresponding to multiple content providers 431, 432, 433, and 434. Here, the broadcasting device transmits the corresponding partial share to each content provider 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 the session key 420, the user equipment must obtain at least three of the four shares (any three of 420A, 420B, 420C, and 420D).

[0078] exist Figure 4A In the example, each user device 441, 442, and 443 registers with each of the content providers 431-434 and receives corresponding share portions 420A, 420B, 420C, and 420D from the respective content providers 431, 432, 433, and 434 during the registration process. Here, user devices 441-443 can register via online interfaces, portals, websites, by mail, by telephone, etc., while the corresponding share portions are delivered electronically, such as via email or downloadable files.

[0079] Now for reference Figure 4B The broadcasting device 420 can encrypt the digital content stream using the session key 420 and broadcast the digital content stream (in encrypted form) to all user devices 441-443. Figure 4BIn the example, user equipment 443 receives an encrypted digital content stream and attempts to reconstruct the session key 420. Here, because user equipment 443 possesses all shares (420A-420D) of the session key 420, it is able to reconstruct the session key 420 and decrypt the digital content stream. Therefore, user equipment 443 is able to consume content streams, which may include live TV, on-demand television, movies, music, etc.

[0080] Figure 4C Another process 400C for distributing a share of the session key according to another example embodiment is shown. Figure 4D Another process 400D for broadcasting content based on a session key, according to an example embodiment, is illustrated. (Reference) Figure 4C Content provider 434 has been compromised by unauthorized user 444. In this example, unauthorized user 444 could be a hacker or other unregistered user who has gained unauthorized access to a portion of the key share 420D controlled by content provider 434. In this example, unauthorized user 444 has added their device to the list of registered users registered with content provider 434 and removed registered user 443 who had already been authorized to access the portion of the key share 420D.

[0081] In this example, after modification by unauthorized user 444, the partial key share 420D can be updated and distributed to all registered users. Therefore, unauthorized user 444 can receive the updated partial key share 420D, while registered user 443 can choose not to receive it. However, refer to... Figure 4D Even if registered user 443 no longer possesses the updated partial key 420D, registered user 443 can still recover the session key. Specifically, registered user 443 still possesses most of the partial shares 420A, 420B, and 420C, and is able to reconstruct the session key 420.

[0082] Meanwhile, unauthorized user 444 can only access a portion of share 420D and cannot reconstruct session key 420. Therefore, unauthorized user 444 cannot decrypt the broadcast content. Thus, by using the threshold encryption scheme employed by the system, the security of the broadcast content is greatly enhanced because it prevents unauthorized access to copies of the digital content, while authorized users can continue to receive even when access permissions have been restricted by unauthorized users.

[0083] Figure 5 Method 500 for broadcast encryption according to an example embodiment is illustrated. As a non-limiting example, method 500 can be performed by a cloud platform, server, blockchain peer, database, etc. References Figure 5In 510, the method may include splitting the session key into multiple partial shares. For example, each key may be divided into multiple partial shares. Each share may be unique. Here, the splitting may be performed based on a threshold encryption scheme, in which a predetermined number of partial shares are required to recover the session key. In some embodiments, the splitting may include dividing the session key into multiple partial shares equal to the number of content providers. In some embodiments, the session key can be recovered from the predetermined number of partial shares, and the predetermined number of partial shares is greater than two partial shares but less than all of the partial shares.

[0084] In step 520, the method may include distributing multiple partial shares to multiple content providers, each content provider receiving a different partial share of the session key. Simultaneously, in step 530, the method may include encrypting the media content stream based on the session key, and in step 540, transmitting the encrypted digital content stream to a user device having one or more of the multiple partial shares. In some embodiments, the transmission may include simultaneously transmitting (e.g., broadcasting) the encrypted digital content stream from a host platform to multiple user devices via a computing network.

[0085] In some embodiments, the method may further include receiving a list of registered user devices that have registered with the digital content stream via a blockchain, and sending a message including broadcasting the encrypted digital content stream 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 provides a different corresponding subset of registered user devices. In some embodiments, the session key may include a private key of a symmetric key pair split into multiple partial shares, and encryption includes encrypting the digital content stream using the public key of the symmetric key pair.

[0086] Figure 6A An example system 600, according to an example embodiment, includes physical infrastructure 610 configured to perform various operations. References Figure 6A Physical infrastructure 610 includes modules 612 and 614. Module 614 includes a blockchain 620 and a smart contract 630 (which may reside on the blockchain 620), which can perform any operational step 608 (in module 612) included in any example embodiment. Step / operation 608 may include one or more embodiments described or depicted, and may represent output or write information written or read from one or more smart contracts 630 and / or blockchain 620. Physical infrastructure 610, module 612, and module 614 may include one or more computers, servers, processors, memory, and / or wireless communication devices. Furthermore, module 612 and module 614 may be the same module.

[0087] Figure 6B Another example system 640, configured to perform various operations according to an example embodiment, is shown. References Figure 6B System 640 includes modules 612 and 614. Module 614 includes a blockchain 620 and a smart contract 630 (which may reside on the blockchain 620), which can perform any operational step 608 (in module 612) included in any example embodiment. Step / operation 608 may include one or more embodiments described or depicted, and may represent output or write information written or read from one or more smart contracts 630 and / or blockchain 620. Physical infrastructure 610, modules 612, and 614 may include one or more computers, servers, processors, memory, and / or wireless communication devices. Furthermore, modules 612 and 614 may be the same module.

[0088] Figure 6C The illustration depicts an example system, according to an exemplary embodiment, configured to utilize smart contract configuration between contracting parties and an intermediary server configured to enforce smart contract terms on a blockchain. References Figure 6C Configuration 650 can represent a communication session, asset transfer session, or process or procedure driven by a smart contract 630 that explicitly identifies one or more user devices 652 and / or 656. The execution, operation, and results of the smart contract execution can be managed by server 654. The content of smart contract 630 may require digital signatures from one or more entities 652 and 656 as parties to the smart contract transaction. The results of smart contract execution can be written to blockchain 620 as a blockchain transaction. Smart contract 630 resides on blockchain 620, which can reside on one or more computers, servers, processors, memory, and / or wireless communication devices.

[0089] Figure 6D A system 660 including a blockchain, according to an example embodiment, is shown. Reference Figure 6D For example, Application Programming Interface (API) Gateway 662 provides a public interface for accessing blockchain logic (e.g., smart contract 630 or other chaincode) and data (e.g., distributed ledger, etc.). In this example, API Gateway 662 is a public interface for executing transactions (calls, queries, etc.) on the blockchain by connecting one or more entities 652 and 656 to the blockchain peer (i.e., server 654). Here, server 654 is a peer component of the blockchain network that holds a copy of the world state and allows clients 652 and 656 to query data on the world state and submit transactions to the distributed ledger in the blockchain network, whereby the endorsing peer will run smart contract 630 according to smart contract 630 and the endorsement policy.

[0090] The above embodiments can be implemented in hardware, as a computer program executed by a processor, firmware, or a combination thereof. The computer program can be embedded on a computer-readable medium, such as a storage medium. For example, the computer program can reside in random access memory (“RAM”), flash memory, read-only memory (“ROM”), erasable programmable read-only memory (“EPROM”), electrically erasable programmable read-only memory (“EEPROM”), registers, hard disks, removable disks, optical disc read-only memory (“CD-ROM”), or any other form of storage medium known in the art.

[0091] An exemplary storage medium may be coupled to a processor, allowing the processor to read information from and write information to the storage medium. Alternatively, the storage medium may be integrated with the processor. The processor and storage medium may reside in an application-specific integrated circuit (“ASIC”). Alternatively, the processor and storage medium may reside as discrete components.

[0092] Figure 7A The process 700, according to an example embodiment, of adding a new block to the distributed ledger 720 is illustrated, and Figure 7B The illustration shows the contents of a new data block structure 730 for blockchain according to an example embodiment. (Refer to...) Figure 7A A client (not shown) can submit transactions to blockchain nodes 711, 712, and / or 713. The client can be an instruction received from any source to formulate an activity on blockchain 720. As an example, the client can be an application acting on behalf of a requester, such as a device, person, or entity, to propose a transaction for use on the blockchain. Multiple blockchain peers (e.g., blockchain nodes 711, 712, and 713) maintain the state of the blockchain network and a copy of the distributed ledger 720. Different types of blockchain nodes / peers can exist in the blockchain network, including endorsement peers that simulate and endorse transactions proposed by clients, and submission peers that verify endorsements, confirm transactions, and submit transactions to the distributed ledger 720. In this example, blockchain nodes 711, 712, and 713 can perform the roles of endorser node, submitter node, or both.

[0093] The distributed ledger 720 comprises a blockchain storing immutable, ordered records in blocks, and a state database 724 (current world state) maintaining the current state of the blockchain 722. Each channel can have its own distributed ledger 720, and each peer maintains its own copy of the distributed ledger 720 for each channel of its members. The blockchain 722 is a transaction log constructed as a hash chain of blocks, where each block contains a sequence of N transactions. Blocks may include, for example... Figure 7BThe various components are shown. Block links can be generated by appending the hash of the header of the previous block to the current block's block header. Figure 7A (As indicated by the arrow in the diagram). In this way, all transactions on Blockchain 722 are ordered and cryptographically linked together, preventing tampering with the blockchain data without breaking the hash links. Furthermore, due to the links, the last block in Blockchain 722 represents every transaction that arrived before it. Blockchain 722 can be stored on a peer-to-peer file system (local or attached storage), with the peer-to-peer file system supporting attaching only the blockchain workload.

[0094] The current state of blockchain 722 and distributed ledger 722 can be stored in state database 724. Here, the current state data represents the latest value of all keys included in the chain transaction log of blockchain 722. Chaincode calls execute transactions against the current state in state database 724. To make these chaincode interactions highly efficient, the latest value of all keys is stored in state database 724. State database 724 can include an indexed view of the transaction log of blockchain 722, and therefore, the indexed view can be regenerated from the chain at any time. State database 724 can be automatically restored (or generated if needed) before accepting transactions.

[0095] Endorsing nodes receive transactions from clients and endorse them based on the simulation results. The endorsing node holds a smart contract for the simulated transaction protocol. 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 method of endorsing a transaction depends on the endorsement policy, which can be specified within the chaincode. An example of an endorsement policy is "a majority of endorsing peers must endorse the transaction." Different channels can have different endorsement policies. The endorsed transaction is forwarded by the client application to the ordering service 710.

[0096] The ordering service 710 accepts endorsed transactions, orders them into blocks, and delivers these blocks to the committing peers. For example, the ordering service 710 can initiate new blocks when a transaction threshold is reached, a timer times out, or another condition is met. Figure 7A In the example, blockchain node 712 is a commit peer that has received a new data block 730 for storage on blockchain 720. The first block in a blockchain can be called the starting block, which includes information about the blockchain, its members, the data stored in it, etc.

[0097] The ordering service 710 can consist of a group of orderers. The ordering service 710 does not process transactions, smart contracts, or maintain a share ledger. Instead, the ordering service 710 can accept endorsed transactions and specify the order in which these transactions are submitted to the distributed ledger 720. The architecture of the blockchain network can be designed to make specific implementations of "ordering" (e.g., Solo, Kafka, BFT, etc.) pluggable components.

[0098] Transactions are written to the distributed ledger 720 in a consistent order. This order is established to ensure that updates to the state database 724 are valid when submitted to the network. Unlike cryptocurrency blockchain systems (such as Bitcoin) that sort transactions through solving cryptographic puzzles or mining, in this example, the parties to the distributed ledger 720 can choose the sorting mechanism best suited to the network.

[0099] When the sorting service 710 initializes a new data block 730, the new data block 730 can be broadcast to commit peers (e.g., blockchain nodes 711, 712, and 713). In response, each commit peer verifies the transactions within the new data block 730 by checking to ensure that the read and write sets still match the current world state in the state database 724. Specifically, the commit peers can determine whether the read data present when the endorser simulates the transaction is the same as the current world state in the state database 724. When a commit peer confirms a transaction, the transaction is written to blockchain 722 on the distributed ledger 720, and the state database 724 is updated with the write data from the read and write sets. If a transaction fails, i.e., if the commit peers find that the read and write sets do not match the current world state in the state database 724, the data of the transaction sorted into the block will still be included in the block, but it will be marked as invalid, and the state database 724 will not be updated.

[0100] refer to Figure 7B A new data block 730 (also called a data block) stored on blockchain 722 of the distributed ledger 720 may include multiple data segments, such as a block header 740, block data 750 (the block data portion), and block metadata 760. It should be understood that... Figure 7B The various blocks and their contents shown, such as the new data block 730 and its contents, are merely examples and are not intended to limit the scope of the example embodiments. In a regular block, a data segment can store transaction information for N transactions (e.g., 1, 10, 100, 500, 1000, 2000, 3000, etc.) within block data 750.

[0101] The new data block 730 can be included within the block header 740 (e.g., Figure 7AThe block header 740 is a link to previous blocks (on block chain 722). Specifically, the block header 740 may include a hash of the header of the previous block. The block header 740 may also include a unique block number for the new data block 730, a hash of the block data 750, etc. The block number of the new data block 730 can be unique and assigned in various orders, such as incremental / sequential starting from zero.

[0102] According to various embodiments, block data 750 may store a list of registered users 752 for digital content. For example, each blockchain peer may store its own corresponding subset of registered users for that blockchain peer. In some embodiments, user list 752 may include updates to previously stored user list 752 for 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 block log on distributed ledger 720. Some benefits of storing user list 752 on the blockchain are reflected in the various embodiments disclosed and described herein. Although in Figure 7B In this embodiment, the user list 752 is depicted in the block data 750, but in other embodiments, the user list 752 may be located in the block header 740 or the block metadata 760.

[0103] Block metadata 760 can store multiple fields of metadata (e.g., as byte arrays). Metadata fields may include a signature about block creation, a reference to the last configured block, transaction filters identifying valid and invalid transactions within the block, and persistent storage of the last offset of a sorting service for sorting blocks. The signature, last configured block, and sorting metadata can be added by the sorting service 710. Simultaneously, the block submitter (such as blockchain node 712) can add validity / invalidity information based on endorsement policies, read / write set verification, etc. Transaction filters may include byte arrays of size equal to the number of transactions included in block data 750 and verification codes identifying whether a transaction is valid / invalid.

[0104] Figure 7C An embodiment of a blockchain 770 for digital content according to embodiments described herein is illustrated. Digital content may include one or more files and associated information. Files may include media, images, videos, audio, text, links, graphics, animations, web pages, documents, or other forms of digital content. The immutable, append-only aspects of the blockchain serve as a security measure to protect the integrity, validity, and authenticity of the digital content, making it suitable for use in legal proceedings where permissive rules are applied or other settings considering the presentation and use of evidence or digital information are of additional interest. In this context, the digital content may be referred to as digital evidence.

[0105] Blockchains can be formed in various ways. In one embodiment, digital content can be included within and accessed from the blockchain itself. For example, each block of the blockchain can store a hash value (e.g., header, value, etc.) of reference information along with the associated digital content. The hash value and the associated digital content can then be encrypted together. Thus, the digital content of each block can be accessed by decrypting each block in the blockchain, and the hash value of each block can be used as a basis for referencing the previous block. This can be illustrated as follows:

[0106] Block 1 Block 2 Block N

[0107] Hash value 1 Hash value 2 Hash value 3

[0108] Digital content 1 Digital content 2 Digital content 3

[0109] In one embodiment, digital content may not be included in the blockchain. For example, the blockchain could store an encrypted hash of the content of each block without any digital content. The digital content could be stored in a separate storage area or memory address associated with the hash value of the original file. This other storage area could be the same storage device used to store the blockchain, or it could be a different storage area, or even a separate relational database. The digital content of each block can be referenced or accessed by obtaining or querying the hash value of the block of interest and then looking up the value stored in the storage area that corresponds to the actual digital content. This operation could be performed, for example, by a database keeper. This can be illustrated as follows:

[0110] Blockchain storage area Block 1 hash value Block 1 hash value ... content Block N hash value Block N hash value ... content

[0111] exist Figure 7C In an example embodiment, blockchain 770 includes multiple blocks 7781, 7782, ... 778 that are cryptographically linked in an ordered sequence. N Where N≥1. Used to link blocks 7781, 7782, ... 778. N The encryption can be any of a number of keyed or unkeyed hash functions. In one embodiment, blocks 7781, 7782, ... 778... NThe input is subjected to a hash function that produces an N-bit alphanumeric output (where N is 256 or another number) based on the information in the block. Examples of such hash functions include, but are not limited to, SHA-type (SHA stands for Secure Hash Algorithm) algorithms, Merkle-Damagard algorithms, HAIFA algorithms, Merkle-tree algorithms, random number-based algorithms, and non-collision-resistant PRF algorithms. In another embodiment, blocks 7781, 7782, ... 778... N Encrypted links can be constructed using functions other than hash functions. For illustrative purposes, the following description is based on hash functions such as SHA-2.

[0112] Blocks 7781, 7782, ... 778 in the blockchain N Each of these includes a header, a file version, and a value. As a result of hashing in the blockchain, the header and value are different for each block. 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.

[0113] The first block in the blockchain, 7781, is called the starting block and includes a header 7721, the original file 7741, and an initial value 7761. The hashing scheme used for this starting block, and indeed in all subsequent blocks, can vary. For example, all the information in the first block 7781 can be hashed together and at once, or each or part of the information in the first block 7781 can be hashed separately, and then the hashing of the separately hashed parts can be performed.

[0114] The header 7721 may include one or more initial parameters, which may include, for example, a version number, timestamp, current value, root information, difficulty level, consensus protocol, duration, media format, source, descriptive keywords, and / or other information associated with the original file 7741 and / or the blockchain. The header 7721 may be generated automatically (e.g., via blockchain network management software) or manually by blockchain participants. This is consistent with other blocks 7782 to 778 in the blockchain. N Unlike the header of the previous block, the header 7721 of the starting block does not reference previous blocks, simply because there are no previous blocks.

[0115] The original file 7741 in the starting block may be data captured by the device, whether processed or not, before the device is included in the blockchain. The original file 7741 is received from the device, media source, or node via a system interface. The original file 7741 is associated with metadata, which may be generated manually or automatically by a user, device, and / or system processor. The metadata may be included in the first block 7781 associated with the original file 7741.

[0116] The value 7761 in the starting 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 include the hash value of the original file 7741, the metadata of 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:

[0117] 1) The hash value of the original file calculated by SHA-2

[0118] 2) Initiate Device ID

[0119] 3) Start timestamp of the original file

[0120] 4) Initial storage location of the original file

[0121] 5) Blockchain network member ID used for the current control source file and related metadata of the software.

[0122] Other blocks 7782 to 778 in the blockchain N It also has a header, filename, and value. However, unlike the first block 7781, the headers in the other blocks are 7722 to 772. N Each of these blocks includes the hash of the immediately preceding block. The hash of the preceding block can be simply the hash of the header of the preceding block, or it can be the hash of the entire preceding block. By including the hash of the preceding block in each remaining block, a block-by-block tracing back to the starting block (and associated original file) can be performed, as shown by arrow 780, to establish an auditable and tamper-proof chain of custody.

[0123] Headers 7722 to 772 in other blocks N Each of these may also include other information such as version number, timestamp, random number, root information, difficulty level, consensus protocol, and / or other parameters or information associated with the corresponding file and / or the blockchain in general.

[0124] Files 7742 to 774 in other blocks N It can be equal to the original file, or it can be a modified version of the original file in the starting block, depending on, for example, the type of processing performed. The type of processing performed can vary between blocks. Processing can involve, for example, any modification to the file in a previous block, such as editing information or otherwise changing the contents of the file, removing information from the file, or adding or appending information to the file.

[0125] Additionally or alternatively, processing may involve only copying a file from a previous block, changing the storage location of a file, analyzing a file from one or more previous blocks, moving a file from one storage or memory location to another, or performing actions relative to the file and / or its associated metadata on the blockchain. Processes involving analyzing files may include, for example, appending, including, or otherwise associating various analyses, statistics, or other information associated with the file.

[0126] Other blocks 7762 to 776 N Each value in a block is unique, and all of these values ​​are distinct as a result of the processing performed. For example, a value in any given block corresponds to a value in a previous block in an updated version. The update is reflected in the hash of the block to which the value was assigned. Therefore, the value of a block provides an indication of what processing was performed within that block and also allows for tracing back through the blockchain to the original file. This tracing confirms the chain of custody of the file throughout the blockchain.

[0127] For example, consider a scenario where a portion of a file in a previous block has been edited, obscured, or pixelated to protect the identity of the person depicted in the file. In this case, the block containing the edited file would include metadata associated with the edited file, such as how the editing was performed, who performed the editing, timestamps of one or more edits occurring, etc. The metadata can be hashed to form this value. Because the metadata of the block differs from the information hashed to form the value in the previous block, these values ​​are distinct from each other and can be recovered during decryption.

[0128] In one embodiment, the value of a previous block can be updated (e.g., a newly calculated hash value) to form the value of the current block when any one or more of the following occur. In this example embodiment, a new hash value can be calculated by hashing all or part of the information mentioned below:

[0129] a) If the file has been processed in any way (e.g., if the file has been edited, copied, altered, accessed, or subjected to some other action), then the new SHA-2 calculated hash value will be...

[0130] b) The new storage location for the file.

[0131] c) New metadata identified and associated with the file.

[0132] d) Transferring access to or control of files from one blockchain participant to another.

[0133] Figure 7D An embodiment of a block that can represent the structure of a block in a blockchain 790 according to one embodiment is shown. (Block)i Including the first 772 i Document 774 i Sum of 776 i .

[0134] First part 772 i Including previous blocks i-1 The hash value and additional reference information, which can be any type of information discussed herein (e.g., header information including references, properties, parameters, etc.). All blocks reference the hash of the previous block, except for the starting block. The hash value of the previous block can be simply the hash of the header in the previous block, or the hash of all or part of the information in the previous block, including files and metadata.

[0135] Document 774 i This includes multiple data sets, such as sequential data 1, data 2, ..., data N. Each data set is tagged with metadata 1, metadata 2, ..., metadata N, describing the content and / or characteristics associated with it. For example, the metadata for each data set may include a timestamp indicating the data, information about the data processing, keywords indicating the people or other content depicted in the data, and / or other information that may help establish the validity and content of the document as a whole, and particularly its usage as digital evidence, for example, as discussed below in conjunction with embodiments. In addition to the metadata, each data set may be tagged with references to previous data (REF 1, REF 2, ..., REF N) to prevent tampering, gaps in the document, and sequential referencing through the document.

[0136] Once metadata is assigned to data (e.g., via smart contracts), it cannot be altered without changing the hash, which can easily be flagged as invalid. Therefore, metadata creates a data log of information that can be accessed and used by participants in the blockchain.

[0137] Value 776 i It is a hash value or other value calculated based on any type of information discussed earlier. For example, for any given block... i The value of the block can be updated to reflect the processing performed on that block, such as a new hash value, a new storage location, new metadata for the associated file, a transfer of control or access, an identifier, or other actions or information to be added. Although the value in each block is shown as separate from the metadata of the file and header data, in another embodiment, the value may be based partly or entirely on that metadata.

[0138] Once the blockchain 770 is established, at any point in time, an immutable chain of custody for the file can be obtained by querying the blockchain to trace the transaction history of values ​​across blocks. This query or tracing process can begin by decrypting the value of the currently most included block (e.g., the last (Nth) block), and then continue decrypting the values ​​of other blocks until the starting block is reached and the original file is recovered. Decryption can also involve decrypting the header and file structure of each block, as well as the associated metadata.

[0139] Decryption is performed based on the type of encryption that occurs within each block. This can involve the use of private keys, public keys, or public-private key pairs. For example, when using asymmetric encryption, blockchain participants or processors in the network can generate public and private key pairs using a predetermined algorithm. The public and private keys are associated with each other through some mathematical relationship. The public key can be publicly distributed to be used as an address to receive messages from other users, such as an IP address or home address. The private key is kept secret and 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 confident that only the sender could have sent the message.

[0140] Generating key pairs is similar to creating an account on the blockchain, but it doesn't require actual registration anywhere. Furthermore, every transaction executed on the blockchain is digitally signed by the sender using their private key. This signature ensures that only the account owner can track and process documents on the blockchain (if within the permissions defined by smart contracts).

[0141] Figure 8A and 8B Further examples of blockchain use cases that can be incorporated into and used in this paper are shown. Specifically, Figure 8A Example 800 of a blockchain 810 storing machine learning (artificial intelligence) data is shown. Machine learning relies on large amounts of historical data (or training data) to build predictive models for making accurate predictions on new data. Machine learning software (e.g., neural networks, etc.) can typically sift through millions of records to find non-intuitive patterns.

[0142] exist Figure 8A In the example, host platform 820 builds and deploys machine learning models for predictive monitoring of asset 830. Here, host platform 820 can be a cloud platform, industrial server, web server, personal computer, user equipment, etc. Asset 830 can be any type of asset (e.g., machinery or equipment), such as aircraft, locomotives, turbines, medical equipment and devices, oil and gas equipment, ships, vessels, vehicles, etc. As another example, asset 830 can be intangible assets, such as stocks, currency, digital coins, insurance, etc.

[0143] Blockchain 810 can be used to significantly improve the training process 802 of machine learning models and the prediction process 804 based on the trained machine learning models. For example, in 802, historical data can be stored on blockchain 810 by the asset 830 itself (or through a medium, not shown), instead of requiring data scientists / engineers or other users to collect the data. This significantly reduces the collection time required by the host platform 820 when performing predictive model training. For example, using smart contracts, data can be directly and reliably transferred directly from its origin to blockchain 810. By using blockchain 810 to ensure the security and ownership of the collected data, smart contracts can directly send data from the asset to the individual using the data to build the machine learning model. This allows data to be shared between assets 830.

[0144] The collected data can be stored on Blockchain 810 based on a consensus mechanism. This consensus mechanism pulls in (permissioned nodes) to ensure that the data being recorded is verified and accurate. The recorded data is time-stamped, cryptographically signed, and immutable. Therefore, it is auditable, transparent, and secure. In some cases (i.e., supply chains, healthcare, logistics, etc.), adding IoT devices that write directly to the blockchain can increase the frequency and accuracy of the recorded data.

[0145] Furthermore, the machine learning model trained on the collected data can be refined and tested in several rounds by the host platform 820. Each round can be based on additional data or data not previously considered to help expand the understanding of the machine learning model. In 802, the different training and testing steps (and the data associated with them) can be stored on the blockchain 810 by the host platform 820. Each refinement of the machine learning model (e.g., changes to variables, weights, etc.) can 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. Additionally, when the host platform 820 has achieved the final trained model, the resulting model can be stored on the blockchain 810.

[0146] After the model has been trained, it can be deployed to a field environment where predictions / decision-making can be made based on the execution of the finally trained machine learning model. For example, in 804, the machine learning model can be used for condition-based maintenance (CBM) of assets such as aircraft, wind turbines, and medical equipment. In this example, data feedback from asset 830 can be fed into the machine learning model and used to make event predictions, such as failure events, error codes, etc. The determinations made by the machine learning model by executing it at host platform 820 can be stored on blockchain 810 to provide auditable / verifiable proof. As a non-limiting example, the machine learning model can predict the future failure / failure of a portion of asset 830 and create an alert or notification to replace that portion. The data behind this decision can be stored on blockchain 810 by host platform 820. In one embodiment, the features and / or actions described and / or depicted herein can occur on or relative to blockchain 810.

[0147] New transactions on a blockchain can be aggregated into a new block and added to an existing hash value. This is then encrypted to create a new hash for the new block. As transactions are encrypted, they are added to the next list of transactions, and so on. The result is a blockchain where each block contains the hash values ​​of all previous blocks. The computers storing these blocks periodically compare their hash values ​​to ensure they are consistent. Any inconsistent computer discards the record that caused the problem. This method is beneficial for ensuring the blockchain's tamper resistance, but it is not perfect.

[0148] One way to manipulate the system is for dishonest users to change their list of favorite transactions while keeping the hash unchanged. This can be done through brute force—in other words, by altering the record, the encryption result, and checking if the hash values ​​are the same. If not, this is repeated until a matching hash is found. The security of blockchain is based on the belief that ordinary computers can only perform such brute-force attacks on completely impractical timescales, such as the age of the universe. In contrast, quantum computers are much faster (1000 times faster), and therefore pose a much greater threat.

[0149] Figure 8B An example 850 of a quantum-secure blockchain 852 implementing quantum key distribution (QKD) to prevent quantum computing attacks is shown. In this example, blockchain users can verify each other's identities using QKD. This uses quantum particles such as photons to send information, which cannot be copied by an eavesdropper without destroying them. In this way, senders and receivers can be certain of each other's identities through the blockchain.

[0150] exist Figure 8BIn this example, there are four users: 854, 856, 858, and 860. Each pair of users can share a key 862 (i.e., QKD) between them. Since there are four nodes in this example, there are six pairs of nodes, thus six different keys 862 are used, including QKD. AB QKD AC QKD AD QKD BC QKD BD and QKD CD Each pair can create a QKD by sending information using quantum particles such as photons, and an eavesdropper cannot copy a QKD without destroying it. In this way, a pair of users can be certain of each other's identity.

[0151] Blockchain 852 operates based on two processes: (i) the creation of transactions and (ii) the construction of blocks that aggregate new transactions. Creating new transactions can be similar to traditional blockchain networks. Each transaction can contain information about the sender, receiver, creation time, amount (or value) to be transferred, a list of reference transactions proving the sender has the funds for the operation, etc. The transaction record is then sent to all other nodes, where it is entered into a pool of unconfirmed transactions. Here, the two parties (i.e., a pair of users from 854-860) authenticate the transaction by providing their shared key 862 (QKD). This quantum signature can be appended to each transaction, making it extremely difficult to tamper with. Each node checks its local copy of the entries for blockchain 852 to verify that each transaction has sufficient funds. However, the transaction is not yet confirmed.

[0152] Instead of performing a traditional mining process on blocks, blocks can be created in a decentralized manner using a broadcast protocol. Within a predetermined time period (e.g., seconds, minutes, hours, etc.), the network can apply the broadcast protocol to any unconfirmed transactions, thereby ensuring a Byzantine agreement (consistency) regarding the correct version of the transactions. For example, each node can possess a private value (the transaction data of that particular node). In the first round, nodes send their private values ​​to each other. In subsequent rounds, nodes transmit the information they received from other nodes in the previous round. Here, honest nodes are able to create a complete set of transactions within a new block. This new block can be added to blockchain 852. In one embodiment, the features and / or actions described and / or depicted herein may occur on or relative to blockchain 852.

[0153] Figure 9An example system 900 supporting one or more of the exemplary embodiments described and / or depicted herein is illustrated. System 900 includes a computer system / server 902 that can operate with a number of other general-purpose or special-purpose computing system environments or configurations. Examples of well-known computing systems, environments, and / or configurations suitable for use with computer system / server 902 include, but are not limited to, personal computer systems, server computer systems, thin clients, fat 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 aforementioned systems or devices.

[0154] Computer system / server 902 can be described in the general context of executable instructions of a computer system, such as program modules executed by the computer system. Typically, program modules can include routines, programs, objects, components, logic, data structures, etc., that perform specific tasks or implement specific abstract data types. Computer system / server 902 can be implemented in a distributed cloud computing environment, where tasks are performed by remote processing devices linked via a communication network. In a distributed cloud computing environment, program modules can reside in local and remote computer system storage media, including memory storage devices.

[0155] like Figure 9 As shown, the computer system / server 902 in the cloud computing node 900 is illustrated in the form of a general-purpose computing device. Components of the computer system / server 902 may include, but are not limited to, one or more processors or processing units 904, system memory 906, and buses that couple various system components, including system memory 906, to the processor 904.

[0156] A bus refers to one or more of several types of bus architectures, including memory buses or memory controllers, peripheral buses, accelerated graphics ports, and processor or local buses that use any of the various bus architectures. By way of example and not limitation, these architectures include the Industry Standard Architecture (ISA) bus, the Microchannel Architecture (MCA) bus, the Enhanced ISA (EISA) bus, the Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnect (PCI) bus.

[0157] Computer system / server 902 typically includes various computer system readable media. Such media can be any available media accessible by computer system / server 902, and it includes volatile and non-volatile media, removable and non-removable media. In one embodiment, system memory 906 implements the flowcharts of other figures. System memory 906 may include computer system readable media in the form of volatile memory, such as random access memory (RAM) 910 and / or cache 912. Computer system / server 902 may also include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, storage system 914 may be provided for reading from and writing to a non-removable, non-volatile magnetic medium (not shown and generally referred to as a "hard disk drive"). Although not shown, a disk drive may be provided for reading from and writing to a removable, non-volatile disk (e.g., a "floppy disk"), and an optical disk 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 this case, each may be connected to a bus via one or more data media interfaces. As will be further described and illustrated below, memory 906 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of various embodiments of the application.

[0158] As an example and not a limitation, a program / utility 916 having a set (at least one) of program modules 918, along with an operating system, one or more applications, other program modules, and program data, may be stored in memory 906. Each of the operating system, one or more applications, other program modules, and program data, or some combination thereof, may include an implementation of a networked environment. Program modules 918 typically perform the functions and / or methods of various embodiments of the applications described herein.

[0159] As those skilled in the art will understand, aspects of this application can be implemented as a system, method, or computer program product. Therefore, aspects of this application can take the form of a completely hardware embodiment, a completely software embodiment (including firmware, resident software, microcode, etc.), or an embodiment combining software and hardware aspects, which can be collectively referred to herein as a “circuit,” “module,” or “system.” Furthermore, aspects of this application can take the form of a computer program product embedded therein in one or more computer-readable media containing computer-readable program code.

[0160] The computer system / server 902 can also communicate with one or more external devices 920, such as a keyboard, pointing device, display 922, etc.; one or more devices that enable a user to interact with the computer system / server 902; and / or any device that enables the computer system / server 902 to communicate with one or more other computing devices (e.g., a network interface card, modem, etc.). This communication can occur via I / O interface 924. Furthermore, the computer system / server 902 can also communicate with one or more networks such as a local area network (LAN), a general area network (WAN), and / or a public network (e.g., the Internet) via network adapter 926. As depicted, network adapter 926 communicates with other components of the computer system / server 902 via a bus. It should be understood that, although not shown, other hardware and / or software components can be used in conjunction 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.

[0161] Although exemplary embodiments of at least one of the systems, methods, and non-transitory computer-readable media are shown in the accompanying drawings and described in the foregoing detailed embodiments, it will be understood that this application is not limited to the disclosed embodiments, but is capable of numerous rearrangements, modifications, and substitutions as set forth and defined in the appended claims. For example, the capabilities of the systems in the various figures may be implemented by one or more of the modules or components described herein or in a distributed architecture, and may include transmitters, receivers, or both in pairs. For example, all or part of the functions performed by the respective modules may be performed by one or more of these modules. Furthermore, the functions described herein may be performed at various times and may be related to various events, either internal or external to the modules or components. Moreover, information transmitted between the various modules may be transmitted between the modules via at least one of the following: data network, Internet, voice network, Internet Protocol network, wireless device, wired device, and / or via multiple protocols. Moreover, messages sent or received by any module may be sent or received directly and / or via one or more other modules.

[0162] Those skilled in the art will understand that the "system" can be implemented as a personal computer, server, console, personal digital assistant (PDA), cellular phone, tablet computing device, smartphone, or any other suitable computing device, or a combination of devices. Presenting the foregoing functionality as being performed by the "system" is not intended to limit the scope of this application in any way, but rather to provide one example of many embodiments. In fact, the methods, systems, and apparatuses disclosed herein can be implemented in a localized and distributed manner consistent with computing technologies.

[0163] It should be noted that some system features described in this specification have been presented as modules to more specifically emphasize their implementation independence. For example, modules can be implemented as hardware circuits comprising custom VLSI circuitry or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. Modules can also be implemented in programmable hardware devices such as field-programmable gate arrays, programmable array logic, programmable logic devices, graphics processing units, etc.

[0164] Modules can also be implemented, at least partially, as software executed by various types of processors. Identifiable units of executable code may, for example, include one or more physical or logical blocks of computer instructions, which may be organized, for example, as objects, procedures, or functions. However, the executable code of the identified module does not need to be physically located together, but may include independent instructions stored in different locations that, when logically combined, comprise the module and achieve its intended purpose. Furthermore, modules can be stored on a computer-readable medium, which may be, for example, a hard disk drive, a flash memory device, random access memory (RAM), magnetic tape, or any other such medium for storing data.

[0165] In practice, a module of executable code can be a single instruction or multiple instructions, and can even be distributed across several different code segments, between different programs, and across several memory devices. Similarly, operational data in this document can be identified and represented within a module, and can be embodied in any suitable form and organized within any suitable type of data structure. Operational data can be collected as a single dataset, or it can be distributed across different locations including different storage devices, and can exist at least in part as electronic signals on a system or network.

[0166] It is readily understood that, as generally described and illustrated in the accompanying drawings, the components of this application can be arranged and designed in a variety of different configurations. Therefore, the specific embodiments described herein are not intended to limit the scope of the claimed application, but are merely representative of selected embodiments of the application.

[0167] Those skilled in the art will readily understand that the above content can be practiced with steps in a different order and / or with hardware components configured differently from the disclosed configuration. Therefore, although this application has been described based on these preferred embodiments, certain modifications, variations, and alternative constructions will be apparent to those skilled in the art.

[0168] Although preferred embodiments of this application have been described, it should be understood that the described embodiments are merely illustrative, and the scope of this application is limited only by the appended claims when considering its full range of equivalents and modifications (e.g., protocols, hardware devices, software platforms, etc.).

Claims

1. An apparatus for broadcast encryption, comprising: A processor configured to split a session key into multiple partial shares, distribute the multiple partial shares to multiple digital rights management (DRM) content providers, and encrypt DRM media content streams based on the session key, wherein the multiple DRM content providers comprise multiple subsets of different registered user devices, and each DRM content provider receives a different partial share of the session key; and A network interface configured to broadcast encrypted DRM media content streams to a subset of registered user devices via a broadcast channel, wherein the session key is configured to decrypt the encrypted DRM media content streams, and a predetermined threshold number of shares of the session key are obtained from a predetermined threshold number of DRM content providers to reconstruct the session key.

2. The apparatus according to claim 1, wherein, The processor is configured to divide the session key into the plurality of partial shares via a threshold encryption scheme.

3. The apparatus according to claim 1, wherein, The processor is configured to divide the session key into a number of portions equal to the number of DRM content providers.

4. The apparatus according to claim 1, wherein, The processor is configured to control the network interface to broadcast the encrypted DRM media content stream from the host platform to a subset of the registered user devices via a computing network.

5. The apparatus according to claim 1, wherein, The predetermined threshold number of a portion is greater than two portions but less than all portions of the plurality of portions.

6. The apparatus according to claim 1, wherein, The network interface is further configured to receive a list of registered user devices that have registered the encrypted DRM media content stream via a blockchain, and to broadcast the encrypted DRM media content stream to the list of registered user devices received from the blockchain.

7. The apparatus according to claim 6, wherein, The blockchain comprises multiple blockchain peers, and each blockchain peer provides a different corresponding subset of registered user devices.

8. The apparatus according to claim 1, wherein, The 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 DRM media content stream via the public key of the symmetric key pair.

9. A method for broadcast encryption, comprising: Split the session key into multiple partial shares; The plurality of partial shares are distributed to a plurality of digital rights management (DRM) content providers, which include a plurality of different subsets of registered user devices, wherein each DRM content provider receives a different partial share of the session key; Encrypt the DRM media content stream based on the session key; and An encrypted DRM media content stream is broadcast to a subset of registered user equipment via a broadcast channel, wherein the session key is configured to decrypt the encrypted DRM media content stream, and a predetermined threshold number of shares of the session key are obtained from a predetermined threshold number of DRM content providers to reconstruct the session key.

10. The method according to claim 9, wherein, The splitting includes dividing the session key into the multiple partial shares via a threshold encryption scheme.

11. The method according to claim 9, wherein, The splitting includes dividing the session key into a portion equal to the number of DRM content providers.

12. The method according to claim 9, wherein, The broadcast includes broadcasting the encrypted DRM media content stream from the host platform to a subset of the registered user devices via a computing network.

13. The method according to claim 9, wherein, The predetermined threshold number of a portion is greater than two portions but less than all portions of the plurality of portions.

14. The method of claim 9, further comprising: The broadcast includes receiving a list of registered user devices that have registered the DRM media content stream via a blockchain, and the broadcast includes broadcasting the encrypted DRM media content stream to the list of registered user devices received from the blockchain.

15. The method according to claim 14, wherein, The blockchain comprises multiple blockchain peers, and each blockchain peer provides a different corresponding subset of registered user devices.

16. The method according to claim 9, wherein, The session key includes a private key of a symmetric key pair that is split into the plurality of partial shares, and the encryption includes encrypting the DRM media content stream using the public key of the symmetric key pair.

17. A non-transitory computer-readable medium including instructions that, when read by a processor, cause the processor to perform a method comprising: Split the session key into multiple partial shares; The plurality of partial shares are distributed to a plurality of digital rights management (DRM) content providers, which include a plurality of different subsets of registered user devices, wherein each DRM content provider receives a different partial share of the session key; Encrypting DRM media content streams based on the session key; and An encrypted DRM media content stream is broadcast to a subset of registered user equipment via a broadcast channel, wherein the session key is configured to decrypt the encrypted DRM media content stream, and a predetermined threshold number of shares of the session key are obtained from a predetermined threshold number of DRM content providers to reconstruct the session key.

18. The non-transitory computer-readable medium according to claim 17, wherein, The splitting includes dividing the session key into the multiple partial shares via a threshold encryption scheme.

19. The non-transitory computer-readable medium according to claim 17, wherein, The splitting includes dividing the session key into a portion equal to the number of DRM content providers.

20. The non-transitory computer-readable medium according to claim 17, wherein, The broadcast includes broadcasting the encrypted DRM media content stream from the host platform to a subset of the registered user devices via a computing network.

Images