External entropy supply for IoT devices employing a RISC-V Trusted Execution Environment

This paper proposes and validates an open-source RISC-V-based Trusted Execution Environment that acts as an external entropy service, enabling constrained IoT devices to securely obtain high-quality random numbers for cryptographic key generation by leveraging initial trust and potentially expanding with additional sensor-based entropy sources.

The Gist

Here is an explanation of the paper using simple language and creative analogies.

The Problem: The "Boring" IoT Device

Imagine you have a fleet of tiny, cheap smart devices (like smart thermostats or sensors) scattered around a city. These devices need to send secret messages to stay safe from hackers. To create a secret code (a cryptographic key), they need entropy—which is just a fancy word for true randomness.

Think of entropy like shuffling a deck of cards. If you shuffle well, the order is unpredictable. If you shuffle poorly, the cards might end up in a predictable pattern, and a hacker could guess the next card.

The Catch: These tiny IoT devices are like children with very small hands. They don't have enough "muscle" (computing power) or "sensors" (like microphones or cameras) to shuffle the deck well enough on their own. They are "entropy starved." If they try to make their own random numbers, they might accidentally create a predictable pattern, leaving their secrets wide open for hackers to steal.

The Solution: The "Randomness Bank"

The authors of this paper propose a solution called Entropy as a Service (EaaS).

Imagine a Bank of Randomness.

• The IoT Devices: These are the customers who need cash (random numbers) but don't have a vault to store it.
• The Server (The Bank): Instead of a normal server, this is a Trusted Execution Environment (TEE). Think of this as a high-tech, bulletproof vault inside the bank. Even if the bank manager (the server operator) is evil or tries to steal, the vault is so secure that no one can peek inside or tamper with what's happening.

How It Works: The Secure Delivery

Here is the step-by-step process of how a tiny device gets its randomness:

1. The Request: A tiny IoT device (the customer) sends a request to the Bank: "I need 100 random numbers, please!" It signs this request with its own ID card so the bank knows who is asking.
2. The Vault (TEE): The request goes into the bulletproof vault (the TEE). Inside this vault, the server gathers "fresh" randomness from various sources (like other sensors or hardware noise). It mixes them together to make a super-random batch.
3. The Proof: The vault doesn't just hand over the numbers. It puts them in a locked box, signs the box with a digital seal, and says, "I promise these numbers are fresh and came from inside my secure vault."
4. The Delivery: The box is sent back to the IoT device. The device checks the seal. If it's valid, it opens the box and uses the random numbers to create its secret keys.

Why This is Special: The "RISC-V" Engine

The paper uses a specific type of computer chip architecture called RISC-V.

• Analogy: Think of RISC-V as Lego. Unlike other chips that are like pre-made, sealed plastic toys, RISC-V is like a box of open Lego bricks. Anyone can build their own custom processor with it.
• The authors built their "Bulletproof Vault" (TEE) using these open Lego bricks. This is a big deal because it means the security isn't a "black box" made by a secret company; it's open for everyone to inspect, which makes it more trustworthy.

The "No Middleman" Trust

Usually, when you trust a server, you have to trust the company running it. But here, the authors use Remote Attestation.

• Analogy: Imagine you are ordering food from a restaurant. Usually, you have to trust the chef. But in this system, the restaurant gives you a live video feed of the kitchen before you eat. You can see the chef putting the ingredients in.
• In the paper, the IoT device gets a digital "video feed" (a cryptographic proof) that proves the server is actually using the secure vault and hasn't been hacked. This removes the need to blindly trust the server operator.

The Result

The team built a working prototype (a "Proof of Concept") using software that simulates this hardware. They showed that:

1. Tiny devices can get high-quality randomness from a central server.
2. The server is so secure that even if the server owner is malicious, the randomness remains safe.
3. This system is built on open-source tools, making it cheap and accessible for the future of the Internet of Things.

In a Nutshell

Tiny devices are too weak to generate their own secret codes. This paper builds a secure, open-source "Randomness Bank" where these devices can borrow high-quality randomness. The bank is so secure (thanks to the TEE and RISC-V technology) that the devices can trust the randomness without ever needing to trust the person running the bank.

Technical Summary

Here is a detailed technical summary of the paper "External entropy supply for IoT devices employing a RISC-V Trusted Execution Environment."

1. Problem Statement

Entropy Starvation in Constrained IoT:
Secure cryptographic operations (key generation, encryption, authentication) require high-quality, unpredictable randomness (entropy). However, many resource-constrained Internet of Things (IoT) devices lack the hardware or computational resources to generate sufficient entropy locally.

• Risks: Entropy starvation leads to predictable cryptographic outputs, compromising key security and enabling attacks.
• Limitations of Existing Solutions:
  • Local TRNGs: Often absent or flawed in low-cost devices.
  • Environmental Sensors: Can be manipulated by adversaries or lack sufficient unpredictability.
  • Pre-installed Keys: Require periodic re-seeding with new entropy to remain secure, which constrained devices cannot do alone.
  • Software Extractors: Computationally expensive for low-power devices.
• The Gap: There is a need for a scalable, secure method to provide external entropy to a fleet of IoT devices without relying on a Trusted Third Party (TTP) that could be compromised.

2. Methodology

The authors propose an Entropy as a Service (EaaS) architecture backed by a Trusted Execution Environment (TEE) on a RISC-V platform. The solution removes the need for a TTP by placing trust in the hardware-enforced isolation of the TEE.

Core Architecture Components

1. Hardware Platform (SPIRS):
   • Based on the RISC-V architecture (specifically the CORE-V CVA6 core).
   • Includes a hardware Root of Trust (RoT) featuring a Physical Unclonable Function (PUF) and True Random Number Generator (TRNG) based on Ring Oscillators.
   • Provides AES-256, SHA-256, and digital signature acceleration.
2. Software Stack (SPIRS TEE SDK):
   • Built on a fork of the open-source Keystone framework.
   • Implements a Security Monitor (SM) running in Machine Mode (M-mode) to manage memory protection (PMP) and mediate access between untrusted and trusted environments.
   • Supports Trusted Applications (TAs) running in the TEE enclave and Client Applications (CAs) in the untrusted Linux user space.
3. The EaaS Protocol:
   • Actors:
     • IoT Client: A constrained device requesting entropy.
     • Trusted Execution Server (TES): A server running the EaaS logic inside a RISC-V TEE.
     • Entropy Sources: A fleet of IoT devices (or other sensors) providing raw entropy to the TES.
   • Workflow:
     1. Initialization: The IoT client holds a pre-provisioned public key of the TES and its own key pair.
     2. Request: The client sends an encrypted HTTP request containing a timestamp ($t_1$), its public key ($pk_{IoT}$), the requested entropy amount ($\Delta S$), and a self-signed signature ($\sigma_1$).
     3. Processing (Inside TEE):
        • The TES verifies the request signature.
        • It fetches raw entropy ($\Delta S_1, \Delta S_2$) from connected entropy sources.
        • It combines this entropy into a strong random value ($S$).
        • It generates a symmetric session key ($sksession$) and a new timestamp ($t_2$).
        • It encrypts the session key with the client's public key.
        • It encrypts the entropy payload ($S$) and timestamp ($t_2$) using the session key.
        • It signs the entire response with its private key ($sk_{TES}$).
     4. Response: The client receives the encrypted payload and signature. It decrypts the session key, verifies the signature, checks the freshness ($t_2 > t_1$), and extracts the entropy.

Security Mechanisms

• No TTP: Trust is derived from the RISC-V TEE hardware and remote attestation, not the server operator.
• Remote Attestation: Uses a Challenge/Response mechanism to verify the integrity of the TES hardware and software state before trust is established.
• Throttling: The TES implements rate limiting to prevent entropy depletion via Denial of Service (DoS) attacks.
• Hybrid Cryptography: Uses RSA-3072 for key exchange/signatures and AES-128 for payload encryption to overcome public key size limitations.

3. Key Contributions

1. SPIRS TEE SDK: The authors designed, developed, and published an open-source SDK for the RISC-V-based SPIRS platform. This enables the development of Trusted Applications (TAs) for RISC-V TEEs, filling a gap in open-source tooling for this architecture.
2. EaaS Implementation: They designed and implemented a functional EaaS Trusted Application. This demonstrates a practical method for a fleet of IoT devices to securely obtain high-quality entropy from a central, attested server.
3. Scalable Entropy Aggregation: The solution allows the aggregation of entropy from multiple sources (e.g., other IoT devices with sensors) to feed the central TES, creating a robust entropy pool.
4. Open-Source Release: The entire codebase, including the SDK and the EaaS demo, is released under an MIT license, promoting reproducibility and further research.

4. Results

• Proof of Concept: The authors successfully implemented the EaaS protocol using the QEMU virtualized environment (simulating the SPIRS hardware) on an Ubuntu 22.04 machine.
• Functionality: The system successfully handled the full lifecycle: provisioning, secure boot, remote attestation, request handling, entropy generation, and secure delivery.
• Feasibility: The results confirm that building a trusted entropy infrastructure for IoT is feasible on open RISC-V platforms using the provided SDK.
• Limitations Identified:
  • The current prototype relies on a single TES (single point of failure), though the design supports load balancing.
  • Development was done on QEMU; mapping OpenSSL to the specific hardware RoT of the physical SPIRS board requires further work.
  • The system currently relies on the specific PUF/TRNG implementation of the SPIRS RoT; if that is flawed, the EaaS output is compromised.
  • Post-Quantum Readiness: The current implementation uses RSA/AES. The authors note the need for Post-Quantum Cryptography (PQC) migration in future deployments to protect against "Harvest-Now-Decrypt-Later" attacks.

5. Significance

• Solving a Critical IoT Vulnerability: This work addresses a fundamental weakness in IoT security (entropy starvation) with a scalable, network-based solution.
• Decentralizing Trust: By leveraging TEEs, the solution eliminates the need for a central authority (TTP) that users must blindly trust. Trust is instead placed in the verifiable hardware properties of the server.
• Advancing RISC-V Security: The paper provides a concrete example of how open-source RISC-V hardware can be used to build secure, high-assurance systems, supported by a new open-source SDK.
• Future Research Direction: The paper highlights EaaS as a distinct and valuable alternative to "Randomness Beacons," offering selective delivery, mutual authentication, and freshness guarantees tailored for IoT fleets.

In conclusion, the paper demonstrates that a RISC-V-based TEE can effectively serve as a secure, external entropy provider for constrained IoT devices, ensuring cryptographic security without requiring local high-quality entropy sources on every device.