Storage
Encryption & Access Control

Encryption and Access Control

Spheron Storage prioritizes data security and privacy, offering users the option to implement robust encryption and decryption processes to safeguard their assets. Here's an overview of how encryption, access control and decryption can be implemented using Spheron Storage.

Encryption

Spheron Storage offers users the option to enhance the security of their assets through encryption. Powered by the Lit Protocol, this encryption ensures that NFT assets remain confidential and accessible only to authorized users.

Here's an example of how encryption works:

const { uploadId, bucketId, protocolLink, dynamicLinks } =
  await spheron.encryptUpload({
    authSig,
    accessControlConditions,
    chain,
    filePath,
    litNodeClient: client,
    configuration: {
      name: bucketName,
    },
  });

Parameters of encryptUpload:

  • authSig - (optional) The authSig of the user. You can use checkAndSignAuthMessage function from @lit-protocol/lit-node-client (opens in a new tab) to create it. Checkout the example (opens in a new tab).

  • sessionSigs: - (optional) the session signatures to use to authorize the user with the nodes.

  • accessControlConditions - (optional) The access control conditions that the user must meet to obtain this signed token. This could be possession of an NFT, for example.

  • evmContractConditions - (optional) EVM Smart Contract access control conditions that the user must meet to obtain this signed token. This could be possession of an NFT, for example. This is different than accessControlConditions because accessControlConditions only supports a limited number of contract calls. evmContractConditions supports any contract call.

  • solRpcConditions - (optional) Solana RPC call conditions that the user must meet to obtain this signed token. This could be possession of an NFT, for example.

  • unifiedAccessControlConditions - (optional) An array of unified access control conditions. You may use AccessControlCondition, EVMContractCondition, or SolRpcCondition objects in this array, but make sure you add a conditionType for each one.

    NOTE: The function requires either accessControlConditions, evmContractConditions, solRpcConditions or unifiedAccessControlConditions.

  • chain - The chain name of the chain that this contract is deployed on.

  • string - (optional) The string you wish to encrypt.

  • file - (optional) The File you wish to encrypt.

    NOTE: The function requires either string of file parameters to be passed.

  • litNodeClient - An instance of LitNodeClient that is already connected.

  • configuration:

    • token - The upload token was fetched from the server.
    • onChunkUploaded - (optional) callback function (uploadedSize: number, totalSize: number) => void. The function will be called multiple times, depending on the upload size. The function will be called each time a chunk is uploaded, with two parameters. The first one uploadedSize represents the size in Bytes for the uploaded chunk. The totalSize represents the total size of the upload in Bytes.

By utilizing the encryptFile function, Spheron Storage ensures that NFT files are encrypted before being uploaded to IPFS. This encryption process adds a layer of security, ensuring that NFT content remains confidential and protected. Only users with the appropriate access control conditions and decryption capabilities can unlock and view the NFTs within the private gallery.

To learn more about how encryption works and how to implement it within Spheron Storage, please refer Encryption for Storage SDK and Browser Upload SDK.

Access Control

Once an asset is encrypted within Spheron Storage, the platform mints it on the blockchain, creating a unique token that represents ownership of the asset. This ownership token is associated with the owner's wallet address, granting them the exclusive ability to decrypt and view the asset's content securely. To achieve this controlled access, Spheron Storage leverages the powerful access controls provided by the Lit Protocol.

Here's an example of how access controls are integrated into an application:

const client = new LitJsSdk.LitNodeClient({});
const chain = "mumbai";
 
const createAccessControlCondition = (id: string) => {
  return [
    {
      contractAddress: process.env.REACT_APP_CONTRACT_ADDRESS,
      standardContractType: "ERC721",
      chain,
      method: "ownerOf",
      parameters: [id],
      returnValueTest: {
        comparator: "=",
        value: ":userAddress",
      },
    },
  ];
};

The createAccessControlCondition function accepts an id parameter representing the unique identifier of an NFT. It constructs an access control condition using the Lit Protocol's access control condition schema.

Let's break down the components of the access control condition:

  1. contractAddress: Specifies the address of the contract associated with the NFT. In this example, we utilise the REACT_APP_CONTRACT_ADDRESS environment variable for flexibility.

  2. standardContractType: Indicates the type of contract, in this case, "ERC721" for non-fungible tokens. The Lit Protocol supports various contract types, enabling flexible access control conditions.

  3. chain: Specifies the blockchain network where the NFT contract resides. In this example, we set it to "mumbai," but it can be adjusted based on the desired blockchain.

  4. method: Specifies the contract method to be called for the access control condition. In this case, we utilise the "ownerOf" method to check if the user's address matches the owner of the NFT.

  5. parameters: Contains any required parameters for the contract method. Here, we pass the id parameter to the "ownerOf" method to verify ownership.

  6. returnValueTest: Defines the conditions that need to be satisfied for the access control to be granted. In this example, we use the comparator as "=" and value as ":userAddress" to compare the user's address with the owner's address returned by the contract.

By implementing and leveraging access control conditions, as demonstrated in the provided code snippet, Spheron Storage ensures that only the rightful owner of an NFT can access and decrypt the locked data associated with their NFT.

Decryption

For authorized users, unlocking a NFT asset within Spheron Storage is a seamless experience. The platform verifies their access rights before allowing decryption. The access control conditions defined by the Lit Protocol play a pivotal role in determining who can decrypt and access the locked NFT data.

Here's an example of how decryption works:

const decryptedData: Uint8Array = spheron.decryptUpload({
  authSig,
  ipfsCid,
  litNodeClient,
});

Parameters of decryptUpload:

  • authSig - (optional) The authSig of the user.
  • sessionSigs - (optional) the session signatures to use to authorize the user with the nodes.
  • ipfsCid - The IPFS cid of the upload that was previously encrypted & uploaded.
  • litNodeClient - An instance of LitNodeClient that is already connected.

To learn more about how decryption works and how to implement it within Spheron Storage, please refer Decryption for Storage SDK and Browser Upload SDK.

Storage ENS DomainsStorage Billing