Secret Management

Defining and enforcing who or what can access a secret and under what conditions. This is implemented through:

• Role-Based Access Control (RBAC): Permissions tied to user roles.
• Multi-Party Computation (MPC): Requiring signatures from multiple parties to authorize a transaction.
• Time-based or Usage-based Policies: Secrets that expire after a set time or number of uses.

The systematic process of periodically updating or replacing secrets to limit the impact of a potential compromise. Key aspects include:

• Automated Rotation: Scheduled, programmatic generation of new API keys or certificates.
• Key Versioning: Maintaining previous key versions during a grace period to avoid service disruption.
• Revocation: The immediate invalidation of a compromised secret, often via a Certificate Revocation List (CRL) or on-chain registry.

The continuous recording and analysis of all interactions with the secret management system. This provides non-repudiation and security insights by logging:

• Every access request, including the identity of the requester and timestamp.
• Successful and failed authentication attempts.
• Changes to access policies or secret metadata.
• These logs are typically immutable and sent to a Security Information and Event Management (SIEM) system.

An advanced cryptographic method that allows a user to prove they possess a secret (like a private key) or meet certain criteria without revealing the secret itself. This enables:

• Privacy-Preserving Authentication: Proving identity or membership without disclosing personal data.
• Selective Disclosure: Revealing only specific, verified attributes from a credential.
• Trustless Authorization: On-chain verification of off-chain credentials, a key component of Decentralized Identity (DID) systems.

Oracle nodes often need to connect to blockchain RPC endpoints (e.g., for submitting transactions or reading on-chain state). These connections may require:

• Private RPC URLs: Endpoints for dedicated node services, often containing embedded API keys.
• Wallet Private Keys: Used to sign transactions that post data on-chain, representing the highest security risk.
• Validator Keys: For oracles operating within Proof-of-Stake networks that also perform validation duties.

Used to access encrypted data feeds or decrypt sensitive information before on-chain delivery. This is critical for confidential data oracles that handle private financial or identity data. Keys are managed separately from the data and applied only during the processing phase within a secure execution environment like a Trusted Execution Environment (TEE) or secure enclave.

Certificates used to establish secure, authenticated connections (HTTPS, WSS) with data providers and other nodes. They ensure data integrity and prevent man-in-the-middle attacks during transmission. Management involves:

• Certificate lifecycle management: Handling issuance, renewal, and revocation.
• Private key protection: The certificate's private key is itself a secret that must be secured.

Cryptographic key pairs that establish a node's unique identity within a decentralized oracle network (e.g., Chainlink nodes, Witnet witnesses).

• The private key signs attestations, proving the data originated from a specific, reputable node.
• Compromise of this key allows an attacker to impersonate the node, potentially corrupting the data feed.
• These are distinct from the wallet keys used for transaction signing.

In oracle networks using threshold cryptography, no single node holds a complete private key. Instead, each node holds a secret share. A data report is only signed and accepted when a threshold number of nodes (e.g., 5 out of 9) collaborate. This decentralizes trust and eliminates single points of failure for key management. The individual share held by each node is a critical secret.

The private key is the cryptographic secret that proves ownership of a blockchain address. Secure storage is non-negotiable.

• Cold Storage (Offline): Hardware wallets and paper wallets keep keys offline, protecting them from remote attacks.
• Hot Storage (Online): Software wallets and browser extensions are convenient but expose keys to malware and phishing.
• Best Practice: Use a hardware wallet for significant holdings and never store a private key in plaintext on a networked device.

A mnemonic phrase (seed phrase) is a human-readable backup, typically 12 or 24 words, that can regenerate all private keys in a wallet.

• Single Point of Failure: Compromising the phrase compromises all derived accounts.
• Secure Backup: Must be written on durable material (e.g., steel plate) and stored physically, separate from digital copies.
• Never Digital: Never store a seed phrase in a cloud service, note-taking app, or as a screenshot, as these are common attack vectors.

Services like node providers, indexers, and exchanges use API keys and RPC endpoints that must be protected.

• Exposure Risks: Leaked keys can lead to unauthorized access, data theft, or resource abuse (e.g., draining rate limits).
• Principle of Least Privilege: Keys should be scoped to the minimum permissions required (read-only vs. write access).
• Rotation & Environment Variables: Keys should be rotated regularly and stored as environment variables, not hardcoded in application source code.

Human error is a major vulnerability. Attackers use deception to trick users into revealing secrets.

• Phishing Sites: Fake websites mimicking legitimate wallets or dApps to harvest seed phrases.
• Impersonation: Scammers posing as support staff in forums or Discord, asking for private keys.
• Mitigation: Always verify URLs, use bookmarklets, and never share secrets. Assume legitimate support will never ask for your private key or seed phrase.

Secrets used within smart contracts (e.g., Oracle API keys, admin private keys for multi-sigs) require specialized management.

• On-Chain Visibility: Data stored on-chain is public. Never commit plaintext secrets to contract storage or constructor arguments.
• Secure Oracles & Keepers: Use decentralized oracle networks (e.g., Chainlink) and secure off-chain keeper services to inject external data or trigger functions without exposing keys on-chain.
• Access Control: Implement robust role-based access control (RBAC) for administrative functions to limit key usage.

Using environment variables is a fundamental practice for keeping secrets out of source code. A .env file stores configuration variables locally, which are loaded at runtime.

• Critical Rule: Never commit .env files to version control (e.g., Git). Use .gitignore.
• Framework Support: Libraries like dotenv in Node.js or python-dotenv simplify this process.

Multi-Party Computation (MPC) is a cryptographic technique that distributes a private key among multiple parties. No single party holds the complete key; transactions require collaboration, eliminating single points of failure.

• Use Case: Enterprise-grade custody, where signing authority is shared across departments or entities.
• Benefit: Enhances security and enables complex governance models for fund management.

Hierarchical Deterministic (HD) Wallets generate a tree of key pairs from a single seed phrase (mnemonic). This allows for managing countless addresses securely without backing up each new private key.

• Standard: Defined by BIP-32 and BIP-44.
• Practice: Securely back up the 12-24 word seed phrase offline. A single compromise of the seed reveals all derived keys.