Phala Network Docs
  • Home
    • 👾Phala Network Docs
  • Overview
    • ⚖️Phala Network
      • 💎Phala Cloud
      • 🥷Dstack
      • 🔐GPU TEE
    • 💎PHA Token
      • 🪙Introduction
      • 👐Delegation
        • Delegate to StakePool
        • What is Vault
        • What is Share
        • WrappedBalances & W-PHA
        • Examples of Delegation
        • Use Phala App to Delegate
        • Estimate Your Reward
      • 🗳️Governance
        • Governance Mechanism
        • Join the Council
        • Voting for Councillors
        • Apply for Project Funding
        • Phala Treasury
        • Phala Governance
        • Setting Up an Account Identity
  • Phala Cloud
    • 🚀Getting Started
      • Create Your Phala Cloud Account
      • Your First CVM Deployment
      • Explore Templates
        • Launch an Eliza Agent
        • Start from Template
    • 🪨TEEs, Attestation & Zero Trust Security
      • Attestation
      • Security Architecture
    • 🥷Phala Cloud User Guides
      • Deploy and Manage CVMs
        • Deploy CVM with Docker Compose
        • Set Secure Environment Variables
        • Deploy Private Docker Image to CVM
        • Debugging and Analyzing Logs
          • Check Logs
          • Private Log Viewer
          • Debug Your Application
        • Application Scaling & Resource Management
        • Upgrade Application
        • Deployment Cheat Sheet
      • Building with TEE
        • Access Your Applications
        • Expose Service Port
        • Setting Up Custom Domain
        • Secure Access Database
        • Create Crypto Wallet
        • Generate Remote Attestation
      • Advanced Deployment Options
        • Deploy CVM with Phala Cloud CLI
        • Deploy CVM with Phala Cloud API
        • Setup a CI/CD Pipeline
    • 🚢Be Production Ready
      • CI/CD Automation
        • Setup a CI/CD Pipeline
      • Production Checklist
      • Troubleshooting Guide
      • Glossary
    • 🔒Use Cases
      • TEE with AI
      • TEE with FHE and MPC
      • TEE with ZK and ZKrollup
    • 📋References
      • Phala Cloud CLI Reference
        • phala
          • auth
          • cvms
          • docker
          • simulator
      • Phala Cloud API & SDKs
        • API Endpoints & Examples
        • SDKs and Integrations
      • Phala Cloud Pricing
    • ❓FAQs
  • Dstack
    • Overview
    • Getting Started
    • Hardware Requirements
    • Design Documents
      • Decentralized Root-of-Trust
      • Key Management Service
      • Zero Trust HTTPs (TLS)
    • Acknowledgement
    • ❓FAQs
  • LLM in GPU TEE
    • 👩‍💻Host LLM in GPU TEE
    • 🔐GPU TEE Inference API
    • 🏎️GPU TEE Benchmark
    • ❓FAQs
  • Tech Specs
    • ⛓️Blockchain
      • Blockchain Entities
      • Cluster of Workers
      • Secret Key Hierarchy
  • References
    • 🔐Setting Up a Wallet on Phala
      • Acquiring PHA
    • 🌉SubBridge
      • Cross-chain Transfer
      • Supported Assets
      • Asset Integration Guide
      • Technical Details
    • 👷Community Builders
    • 🤹Hackathon Guides
      • ETHGlobal Singapore
      • ETHGlobal San Francisco
      • ETHGlobal Bangkok
    • 🤯Advanced Topics
      • Cross Chain Solutions
      • System Contract and Drivers
      • Run Local Testnet
      • SideVM
    • 🆘Support
      • Available Phala Chains
      • Resource Limits
      • Transaction Costs
      • Compatibility Matrix
      • Block Explorers
      • Faucet
    • ⁉️FAQ
  • Compute Providers
    • 🙃Basic Info
      • Introduction
      • Gemini Tokenomics (Worker Rewards)
      • Budget balancer
      • Staking Mechanism
      • Requirements in Phala
      • Confidence Level & SGX Function
      • Rent Hardware
      • Error Summary
    • 🦿Run Workers on Phala
      • Solo Worker Deployment
      • PRBv3 Deployment
      • Using PRBv3 UI
      • PRB Worker Deployment
      • Switch Workers from Solo to PRB Mode
      • Headers-cache deployment
      • Archive node deployment
    • 🛡️Gatekeeper
      • Collator
      • Gatekeeper
  • Web Directory
    • Discord
    • GitHub
    • Twitter
    • YouTube
    • Forum
    • Medium
    • Telegram
Powered by GitBook
LogoLogo

Participate

  • Compute Providers
  • Node
  • Community
  • About Us

Resources

  • Technical Whitepaper
  • Token Economics
  • Docs
  • GitHub

More

  • Testnet
  • Explorer
  • Careers
  • Responsible Disclosure

COPYRIGHT © 2024 PHALA.LTD ALL RIGHTS RESERVED. May Phala be with you!

On this page
  • Key Hierarchy Management
  • Future Security Mechanism

Was this helpful?

Edit on GitHub
  1. Tech Specs
  2. Blockchain

Secret Key Hierarchy

PreviousCluster of WorkersNextSetting Up a Wallet on Phala

Last updated 2 years ago

Was this helpful?

Key Hierarchy Management

The world’s first key hierarchy for blockchain-TEE hybrid system was proposed by the [Ekiden in 2019 and serves as the basis for the Oasis project. As a compute cloud, Phala improves this design to make it viable for a network of ~100k nodes. We also introduce novel mechanisms like key rotation to further improve the robustness of the cloud.

Before we really dig into the details of our contract key management, it’s important for readers to know that every entity in our system has its own identity key. Every user has their account, and every worker and gatekeeper (which are elected by the workers) has its own sr25519 WorkerKey pair, which is generated inside pRuntime (so also in SGX) and the private key never leaves the SGX. The identity key is used to:

  • Identify an entity’s message with signing;

  • Establish an encrypted communication channel between users, workers, and gatekeepers with ECDH key agreement. By default, any communication between any entities is encrypted in Phala.

MasterKey is the root of trust for the whole network. All the contract-related keys, including ClusterKey and ContractKey, are derived from MasterKey. MasterKey is generated and shared by all the gatekeepers (through the encrypted communication channel mentioned above), making the security of MasterKey totally dependent on the security of gatekeepers. This is why gatekeepers are distinguished from other workers in that:

  • Gatekeepers are workers of top confidence level: they are immune to all known SGX vulnerabilities;

  • Unlike normal workers, the endpoints of gatekeepers are not public and you cannot deploy contracts to them. This reduces remote access to gatekeepers;

  • Increased staking amounts are required from gatekeepers to discourage bad behavior from their operators.

Finally, when a contract is deployed to a cluster, it’s deployed to all the workers in that cluster. These workers will follow the deterministic process and derive the ClusterKey to get the same ContractKey. The ContractKeys are unique for different contracts.

What are the consequences if certain keys are leaked?

If a WorkerKey is leaked, the attackers can decrypt all the messages sent to it such as the ClusterKey of its cluster, which can be used to access the ContractKeys of that cluster. Attackers could even impersonate a worker to provide false results to users. Such malicious activity can be detected by comparing the results from multiple workers, and then the chain would slash the compromised worker and confiscate that worker’s staked PHA;

If a ContractKey is leaked, the attackers can decrypt the states and all the historical inputs of that contract;

If a ClusterKey is leaked, the attackers can know the above information of all the contracts in that cluster;

If the MasterKey is leaked, then all historical data is leaked.

What can we do if the worst case happens?

Phala has implemented the Key Rotation for gatekeepers, which means that with the permission of the Council, gatekeepers can update the MasterKey, then correspondingly the ClusterKeys and ContractKeys.

So when the worst case happens, we will first register the new gatekeepers with the latest hardware, deregister all the old ones (since they are likely to be vulnerable) and switch to a new MasterKey.

Future Security Mechanism

  • Use Multi-Party Computation to manage MasterKey

    • Currently, the same MasterKey is shared across all gatekeepers, so it’s leaked if any one of them is compromised. By turning this into MPC, the attackers will have to compromise a majority of the gatekeepers to access the MasterKey.

In Phala, workers are grouped into clusters to provide serverless computing services. A unique ClusterKey is generated for each cluster using the MasterKey (through ), but you cannot revert this process to infer the MasterKey given the ClusterKey. The ClusterKey is shared with all the workers in that cluster.

⛓️
key derivation
paper