darkblock-logo
Darkblock Docs
darkblock-logo
Darkblock Docs
What is Darkblock?

The Darkblock Protocol

A Protocol Enabling Monetization of Content in Web3
​
⁠
⁠

The Darkblock Protocol uses a decentralized network of nodes to control access to digital content associated with NFTs. It can be thought of as a new method of DRM that puts creators in control of distribution and monetization of their content, giving them the freedom to determine business models that work best for them.
To create access controlled content, creators will first reach out to the network to create an encryption key, use this encryption key to encrypt the content and create an
Arweave
⁠
transaction with specified metadata tags, and setting the encrypted content as a payload. The specification of this transaction can be found in the appendix.
⁠
Protocol Diagram
⁠
⁠
Each node in the network has a REST API that can be leveraged to issue encryption keys and act as a proxy to decrypt content that is stored on Arweave in encrypted form. Each node will have a device-level symmetric key and an asymmetric public/private key pair both created when it first initializes that is used to store keys and metadata securely, as well as communicate securely with other nodes. Each node will employ a TEE that remotely attests it is running verified software in a secure manner in order to join and participate in the network.
To create protected content, a user will query Arweave to get a list of verified nodes. It will then reach out to a node to request an encryption key and associated generated UUID that is generated for each piece of content. That encryption key will be encrypted and stored on Arweave to make it available to other nodes and referenced by the UUID. For proper redundancy, the issuing node will have a list of other devices in the network along with their RSA public keys. It will encrypt the content-specific AES-256 key with the device-level RSA public key from X different nodes and place that data in Arweave. Potentially we can use hierarchical deterministic key generation to reduce the need for redundant key storage. We are also exploring threshold techniques to decrease reliance on external storage of keys, and require a number of nodes to work together to access content, thus increasing security.
⁠
image.png
⁠
⁠
To decrypt the content, a client application needs to supply a proof of access (signed message) and an encryption key to deliver the content securely. The client retrieves an enclave's public key and encrypts and securely sends the proof and encryption key. If access is proven by the network (through verification by a 3rd party service or on-chain) the content is retrieved by the TEE and decrypted securely inside the enclave, then re-encrypted using the client application supplied key. Final decryption happens client-side using the client-generated key. The result is effective, but not provable, end-to-end encryption.

Next Steps: V2.1
​
⁠
⁠

In v2.1 we will move the re-encryption process outside the TEE using a new symmetric re-encryption process. Instead of doing the re-encryption inside the TEE we will create a transformation key inside the TEE and then export it for use outside the TEE. This transformation key would atomically re-encrypt data without being given access to it. This will allow us to scale the delivery of content to a simpler layer that does not have the same security requirements. But our holy grail is to move everything outside the TEE. We have ideas for that, but that will probably be v3.
Want to print your doc?
This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (
CtrlP
) instead.