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
  • The Problem
  • Building Blocks
  • System Design
  • DeRoT Certificate Registration
  • TEE App Registration
  • Protection against Unauthorized Certificate Changes

Was this helpful?

Edit on GitHub
  1. Dstack
  2. Design Documents

Zero Trust HTTPs (TLS)

PreviousKey Management ServiceNextAcknowledgement

Last updated 6 months ago

Was this helpful?

The Problem

In this article, we answer a practical question: How to ensure that the certificate for a specific domain is controlled and can only be controlled by a TEE program (in our case, the DeRoT). Once we can achieve this, DeRoT, as the root of trust, can then sign more certificates for every application it has verified. This will be an important building block to enable users to seamlessly verify whether an application is actually running within valid TEEs using the existing TLS-based protocols (like HTTPS). The DeRoT-controlled certificate can not only prove its identity under this paradigm, but extend the chain of trust from the blockchain ecosystem to any website.

Given the key management protocol mentioned above, the DeRoT becomes the root-of-trust of the whole system as it is responsible for verifying all the TEE hardware and managing the data encryption. Its identity can be verified with the RootPubKey published on-chain.

If the DeRoT can use this RootKey as the certificate’s private key, then it owns a TLS certificate which is verifiable on chain and can issue certificates to valid TEE applications running in verified hardware. Since the DeRoT is running inside TEE, it is not hard to generate a certificate that never leaves TEE. The real challenge here is how to ensure this certificate is tightly bound with a domain and cannot be replaced, given that the DNS servers are centralized services that cannot be controlled by smart contract or TEE application.

Building Blocks

Here we introduce two extra building blocks:

  • Certification Authority Authorization (CAA) in DNS record. This is used to specify which certificate authorities (CAs) are permitted to issue certificates for their domain. It prevents unauthorized issuance of SSL/TLS certificates. With CAA, we can ensure that the DeRoT-owned certificate is the only valid one for its domain.

  • Certificate Transparency (CT) is an Internet security standard for monitoring and auditing the issuance of digital certificates. Although the CAA ensures the DeRoT ownership over the certificate, the CAA itself, which can be configured in centralized service providers, may be changed. The CT logs can be used for two purposes: 1) to verify whether the CAA is really set to the expected certificate, and 2) to enable users to detect and reject unauthorized CAA modifications.

System Design

Here we introduce the certificate managing module in the DeRoT serving as a reverse proxy for applications running in the network. It’s worth noting that as a part of DeRoT, it runs in TEE and is also governed by the smart contract.

DeRoT Certificate Registration

The DeRoT will generate a x.509 certificate using the RootKey as the private key. Compared with other TLS certificates, the only difference is that the RootPubKey is available on-chain, so any users can verify that this certificate is really owned by DeRoT.

We further utilize CAA records to restrict the authentication methods, as some of them are not secure. For example, when verifying with HTTPS, Let’s Encrypt only requires you to place a specific text file at http://<your-domain>/verify.txt to confirm domain ownership. However, Let’s Encrypt cannot verify whether the endpoint is within a TEE. To address this, we limit the authentication method to API access only, which can be fully controlled by a TEE. This ensures that there is no possibility of issuing the certificate to an incorrect target.

TEE App Registration

Although a senior user can request to verify the Remote Attestation report from a TEE app directly, most of the users could delegate the verification to DeRoT by verifying its certificate.

To get reverse proxy from DeRoT, a TEE app needs to register itself to DeRoT, during which DeRoT will do the RA verification on it to ensure the DeRoT policy is followed.

Protection against Unauthorized Certificate Changes

Since the DNS servers are centralized services which cannot be controlled by smart contracts, there is risk that the attackers will change the DNS record to break the limitation on the certificate owner.

Although we cannot technically prevent this, we can monitor the unexpected DNS record updates and notify the clients to avoid trusting invalid certificates.

This certificate is sent to CA (e.g. Let’s Encrypt) for signing, then a DNS CAA record is registered. In the example above, the CAA record means “only is allowed to issue certificates for ”.

letsencrypt.org
derot.com