Seal Decentralized Secrets Management

Seal is a decentralized secrets management (DSM) product designed to secure sensitive data at rest on decentralized storage (such as Walrus) or any other onchain/offchain storage.

Key features include:

• Identity-based encryption/decryption: Secure data using identity-based primitives.
• Onchain access control: Access to sensitive data is controlled by onchain policies on the Sui network.
• Threshold-based decryption: Lightweight key servers enforce Sui policies and provide threshold-based decryption keys.
• Developer integration: Easily integrate Seal into applications using the official TypeScript SDK.

Seal is a decentralized secrets management (DSM) service. It allows application developers and users to secure sensitive data at rest on decentralized storage (such as Walrus) or any other onchain/offchain storage. The service relies on access control policies that are defined and validated on the Sui blockchain.

The Move package provides the core onchain functionality for:

• Registering and managing key servers.
• Performing decryption using Boneh-Franklin key encapsulation (over BLS12-381) and HMAC-256-CTR as the data encapsulation mechanism (DEM).

Seal uses Identity-Based Encryption (IBE) to secure data without having visibility into the data itself. In this model, an identity (a string or byte array) acts as a public key.

Key components of the IBE scheme used by Seal:

• Setup: Generates a master secret key (msk) and a master public key (mpk).
• Derive(msk, id): Generates a specific secret key (sk) for a given identity (id) using the master secret key.
• Encrypt(mpk, id, m): Encrypts a message m using the master public key and the identity id.
• Decrypt(sk, c): Decrypts the ciphertext c using the derived secret key sk.

Seal maps onchain Sui strings to these IBE identities. A Move package at a specific address (PkgId) acts as an identity namespace, controlling a subdomain of identities that follow the pattern [PkgId]*.

Seal supports two operational modes for independent server type key servers:

• Open mode: Allows anyone to request keys for any access policy package using a shared master key. This is ideal for public use, trials, or experimentation.
• Permissioned mode: Restricts access to specific approved access policy packages per client. Each client uses a dedicated master key and the mode supports secure key server rotation or switching. This is designed for dedicated or commercial applications.

When integrating, note that for Permissioned mode, you typically need to contact the provider to configure your client and generate a unique key server object ID.

The Secure Voting pattern enables running a vote where ballots remain encrypted until the voting period is complete.

Workflow:

1. Define eligible voters.
2. Voters submit their encrypted choices.
3. Once all votes are submitted, participants fetch the required threshold keys from Seal.
4. Use onchain decryption to produce a verifiable tally.

Invalid or tampered ballots are ignored by the process.

Best use cases:

• Governance
• Sealed-bid auctions
• Time-locked voting

Time-lock encryption allows you to publish encrypted content that automatically unlocks at a specific timestamp. The content is encrypted once with an unlock timestamp; no one can access it before the time passes, and anyone (or a specific audience) can access it after.

Best use cases:

• Coordinated reveals (drops, auctions)
• MEV-resilient trading
• Secure voting

Note: An optional variant exists that allows an authorized party to extend the unlock time before it expires.

Select an encryption mode based on your performance and use-case requirements:

• AES: Use for most application data. It is significantly faster and more memory-efficient than HMAC-CTR.
• HMAC_CTR: Use only when you require onchain decryption of small-sized data.

The Subscription pattern provides time-limited access to encrypted content or services. A service is defined with a specific price and duration. Upon subscribing, a user's identity is granted a 'pass' that permits decryption of the service's content until the subscription expires. This pattern avoids the need for re-encryption or moving data.

Best use cases:

• Premium media
• Data feeds
• Paid API and AI model access

Seal supports threshold encryption using multiple independent key servers. When encrypting data, you must select a threshold configuration (e.g., 2-of-3 or 3-of-5) based on data sensitivity and required availability.

Risks of poor configuration:

• Data Loss: If too many key servers in a configuration go offline or become unavailable, users may be unable to obtain enough decryption shares to recover their keys.
• Security vs. Availability: Always balance the desired security guarantees against the risk of losing access due to server unavailability.

:::note Choosing a specific threshold configuration does not apply to decentralized (committee mode) key servers, as one is defined for each such key server during its setup. :::