Secure Enclaves: Code’s Unbreachable Vault

Fortifying Critical Code with Hardware-Backed Trust

In today’s interconnected digital landscape, the security of sensitive data and critical code is paramount. High-profile data breaches are a constant threat, and the rise of AI and machine learning, coupled with increasing regulatory scrutiny (like GDPR and CCPA), demands innovative solutions for protecting information not just at rest or in transit, but while it’s being processed. This is where Trusted Execution Environments (TEEs)step in as a game-changer. TEEs are isolated, hardware-backed environments designed to protect code and data from unauthorized access or modification, even from privileged software like operating systems or hypervisors. For developers, mastering TEEs means unlocking the ability to build truly robust, privacy-preserving applications, ensuring that even your most critical algorithms and sensitive user data remain impervious to sophisticated attacks. This article will equip you with the insights and practical knowledge to navigate the world of TEEs and elevate your application security.

Photo by Dithira Hettiarachchi on Unsplash

Embarking on Your Journey into Secure Enclaves

Getting started with Trusted Execution Environments might seem daunting due to their hardware-backed nature, but the fundamental concepts and initial steps are surprisingly accessible for developers. The core idea is to designate a portion of your application, and the data it operates on, to run within a cryptographically isolated environment – the “enclave” – where its integrity and confidentiality are guaranteed by the hardware itself.

The primary entry points for developers typically involve platforms like Intel Software Guard Extensions (SGX) or ARM TrustZone. For the sake of practicality, we’ll focus on the general workflow that applies across most TEE implementations.

Step 1: Understanding Your Need for a TEE Before diving into code, identify the specific parts of your application that handle highly sensitive data or critical algorithms that absolutely must remain confidential and untampered. Not all code needs to be in an enclave, only the “crown jewels.” This might be a function that processes biometric data, decrypts a master key, or executes a proprietary AI model.

Step 2: Choosing Your TEE Platform and SDK Most TEEs come with a Software Development Kit (SDK) that provides the necessary tools, libraries, and APIs.

• Intel SGX:Widely used in data centers and cloud environments. The Intel SGX SDK provides libraries and utilities for creating, loading, and managing enclaves. You’ll typically write your enclave code in C/C++.
• ARM TrustZone:Common in mobile devices and IoT. Development often involves Trusted Firmware-M (TF-M) and tools specific to embedded systems.
• Open Enclave SDK:A Microsoft-led open-source project that offers a common API for developing TEE applications across different hardware platforms (like Intel SGX and ARM TrustZone). This is an excellent choice for platform-agnostic development.

For a beginner, the Open Enclave SDK with Intel SGX as the target backend offers a good balance of abstraction and industry relevance.

Step 3: Setting Up Your Development Environment (Example with Open Enclave SDK)

1. Prerequisites:You’ll need a Linux environment (Ubuntu is common) and a machine with Intel SGX enabled in the BIOS. For initial development and testing, you can often use a “simulation mode” where hardware is not strictly required, though it lacks true TEE security.
2. Install Essential Tools:

   sudo apt update
   sudo apt install build-essential cmake libssl-dev libcurl4-openssl-dev pkg-config
   

3. Install Open Enclave SDK:Follow the instructions on the official Open Enclave GitHub repository. This usually involves adding their package repository and installing the SDK:

   echo "deb [arch=amd64] https://packages.microsoft.com/ubuntu/20.04/prod focal main" | sudo tee /etc/apt/sources.list.d/msprod.list
   sudo apt update
   sudo apt install open-enclave
   

   (Note: Adjust 20.04 and focal for your specific Ubuntu version.)

Step 4: Writing Your First Enclave Application (Conceptual Overview)

A TEE application typically consists of two parts:

1. The Host Application:A regular application running outside the enclave. It’s responsible for loading the enclave, communicating with it, and handling non-sensitive operations.
2. The Enclave Application:The secure code and data that resides within the TEE. It exposes specific functions (ECALLs - Enclave Calls) that the host can invoke. Data passed between host and enclave must be explicitly marshalled and unmarshalled.

Conceptual “Hello World” Example:

• Enclave Code (enclave.c):

  #include <openenclave/enclave.h>
  #include "enclave_u.h" // Generated header for ECALLs // An ECALL function callable from the host
  int enclave_print_message(const char message)
  { // This message processing happens securely inside the enclave // Even if the OS is malicious, it cannot see 'message' content or execution // except for its input/output parameters. oe_host_printf("Enclave received message: %s\n", message); return 0;
  }
  

• Host Code (host.c):

  #include <stdio.h>
  #include <openenclave/host.h>
  #include "enclave_u.h" // Generated header for ECALLs // Function to create and call the enclave
  int create_and_call_enclave()
  { oe_enclave_t enclave = NULL; oe_result_t result = OE_OK; // 1. Create the enclave (load the signed enclave binary) result = oe_create_enclave("enclave.signed", OE_ENCLAVE_TYPE_SGX, 0, 0, &enclave); if (result != OE_OK) { fprintf(stderr, "Failed to create enclave: %u\n", result); return -1; } // 2. Call an ECALL function within the enclave const char sensitive_data = "This secret should only be seen by the enclave!"; int ret = 0; result = enclave_print_message(enclave, &ret, sensitive_data); // Calling ECALL if (result != OE_OK || ret != 0) { fprintf(stderr, "Failed to call enclave function: %u\n", result); } else { printf("Host: Successfully called enclave function.\n"); } // 3. Terminate the enclave oe_terminate_enclave(enclave); return 0;
  } int main() { return create_and_call_enclave();
  }
  

This simplified flow demonstrates the core interaction: the host creates the secure environment, passes sensitive data or instructions, the enclave processes them in isolation, and returns a result. It’s a fundamental pattern for building TEE-powered applications, laying the groundwork for more complex secure computations.

Powering Up Your Secure Development with TEE Tools & Ecosystem

Developing for Trusted Execution Environments demands specific tools and a solid understanding of the surrounding ecosystem. While the core programming might be in C/C++, the specialized nature of TEEs introduces unique elements that traditional development workflows often don’t fully address out-of-the-box.

Essential SDKs and Development Frameworks:

1. Open Enclave SDK (OE SDK):As highlighted earlier, this is a fantastic starting point. It provides a unified API surface across different TEE hardware (Intel SGX, ARM TrustZone). This abstraction greatly simplifies the developer experience by reducing platform-specific complexities. It includes:

   • Enclave Definition Language (EDL):Used to define the ECALLs (Enclave Calls) and OCALLs (Outside Calls) interface between the host and the enclave. The OE SDK tools then generate the necessary proxy functions.
   • Build Tools:Integrates with CMake for compiling and signing enclave binaries.
   • Runtime Libraries:For both host and enclave, handling secure memory management, cryptographic operations, and communication.
   • Installation Guide:Covered in the “Getting Started” section, typically via package managers or building from source on Linux.

2. Intel SGX SDK:For direct SGX development without the Open Enclave abstraction, this SDK offers granular control. It provides libraries, drivers, and utilities necessary for creating and managing SGX enclaves.

   • Installation:Involves installing the SGX driver, platform software (PSW), and the SDK itself, usually available as .deb or .rpm packages for Linux distributions.
   • Usage:More verbose than OE SDK, requiring a deeper understanding of SGX architecture.

3. ARM TrustZone / Trusted Firmware-M (TF-M):For embedded systems and microcontrollers utilizing ARM TrustZone, TF-M is the reference implementation for the Platform Security Architecture (PSA) certified TEE.

   • Installation:Typically involves cloning the TF-M repository, configuring for a specific board, and building with ARM toolchains (e.g., GCC ARM Embedded).
   • Usage:Focuses on secure boot, secure storage, and crypto services for resource-constrained devices.

Code Editors and Extensions for Enhanced DX:

While there isn’t a dedicated “TEE IDE,” modern code editors like Visual Studio Codeare highly adaptable and can significantly improve the developer experience.

• C/C++ Extensions (Microsoft):Indispensable for TEE development, as most enclave code is written in C/C++. Provides intelligent autocompletion, go-to-definition, code formatting, and robust debugging capabilities.
  • Installation:Search for “C/C++” in the VS Code Extensions Marketplace and install the one by Microsoft.
  • Usage:Configure c_cpp_properties.json to include paths to your TEE SDK headers (e.g., /opt/openenclave/include) and libraries for accurate IntelliSense.
• CMake Tools (Microsoft):Given that most TEE SDKs leverage CMake for build automation, this extension is crucial. It simplifies configuring, building, and debugging CMake projects directly from VS Code.
  • Installation:Search for “CMake Tools” in the Extensions Marketplace.
  • Usage:After installing, open your project folder containing CMakeLists.txt. The extension will auto-detect the project and allow you to select kits, configure, build, and run targets via the VS Code command palette.
• GitLens (GitKraken):Version control is critical for TEE projects, just like any other. GitLens enhances Git capabilities within VS Code, offering powerful blame annotations, commit history, and repository exploration.
  • Installation:Search for “GitLens” in the Extensions Marketplace.
  • Usage:Provides inline blame, enabling quick understanding of who changed what code and when, invaluable for secure code reviews.

Debugging and Testing Tools:

Debugging within an enclave presents unique challenges due to its isolated nature. Traditional debuggers cannot directly inspect enclave memory.

• Enclave Debuggers: TEE SDKs often provide specialized debugging support. For Intel SGX, a modified GDB version or specific Intel tools might be used, often requiring “debug mode” enclaves which have relaxed security constraints (and should never be used in production).
  • Usage:The Open Enclave SDK supports debugging via GDB with specific command-line arguments to attach to the enclave process. This usually involves stopping the host application at a point where the enclave is loaded, then attaching GDB to the enclave, or launching the application under GDB with the appropriate TEE environment variables set.
• Testing Frameworks:Standard unit testing frameworks like Google Test or Catch2 can be adapted. For enclave-specific logic, tests are often run within the enclave itself, with results communicated back to the host. For integration testing, the host application will create and interact with the enclave as part of its test suite.
• Static Analysis Tools: Tools like Coverity, PVS-Studio, or even clang-tidy are vital for identifying potential vulnerabilities, buffer overflows, or uninitialized variables before they enter the enclave, where debugging and patching are more complex. Integrating these into your CI/CD pipeline is a best practice.

Real-World Fortifications: TEE Examples and Practical Patterns

Trusted Execution Environments aren’t just theoretical; they’re actively safeguarding critical operations across various industries. Understanding their practical application provides insight into how developers can leverage TEEs for robust security.

Photo by Clint Patterson on Unsplash

Code Examples: A Glimpse Inside the Enclave

Let’s expand on our earlier conceptual example to illustrate a more practical scenario: securely hashing sensitive user data before storing it, ensuring the raw data is never exposed outside the enclave.

Scenario:A service needs to hash user passwords (or PII) for storage but wants to guarantee that the hashing function itself, and the plain-text input, are never accessible to even a compromised OS or hypervisor.

Enclave Definition Language (enclave.edl):

enclave { trusted { public int generate_secure_hash([in, string] const char sensitive_data, [out] char hash_output, size_t hash_output_size); };
};

This defines an ECALL generate_secure_hash that takes a sensitive string and outputs a hash. [in, string] and [out] denote marshalling directions.

Enclave Code (enclave.c):

#include <openenclave/enclave.h>
#include "enclave_t.h" // Generated by EDL
#include <string.h>
#include <stdlib.h> // For malloc/free if using dynamic allocation inside enclave, often avoided // Placeholder for a cryptographic hash function (e.g., SHA256)
// In a real scenario, use a robust crypto library like mbed TLS within the enclave.
void simple_sha256_hash(const char input, char output) { // This is a highly simplified placeholder for demonstration. // DO NOT use this for real security. size_t len = strlen(input); for (size_t i = 0; i < len; ++i) { output[i] = input[i] ^ 0xAA; // Simple XOR for demonstration } output[len] = '\0'; // Null terminate
} int generate_secure_hash(const char sensitive_data, char hash_output, size_t hash_output_size)
{ if (!sensitive_data || !hash_output || hash_output_size == 0) { return -1; // Invalid arguments } // Input 'sensitive_data' is now securely inside the enclave // The hashing operation happens here, isolated from the host/OS simple_sha256_hash(sensitive_data, hash_output); // Use a real hash function! // The 'hash_output' will be copied back to the host, but the // original 'sensitive_data' remains within the enclave's secure memory // (or is overwritten/zeroed out if no longer needed). return 0; // Success
}

Host Code (host.c):

#include <stdio.h>
#include <openenclave/host.h>
#include "enclave_u.h" // Generated by EDL
#include <string.h> #define HASH_SIZE 33 // e.g., for SHA256 output + null terminator int main()
{ oe_enclave_t enclave = NULL; oe_result_t result; char hashed_data[HASH_SIZE]; // Create the enclave result = oe_create_enclave("enclave.signed", OE_ENCLAVE_TYPE_SGX, 0, 0, &enclave); if (result != OE_OK) { fprintf(stderr, "Failed to create enclave: %s\n", oe_result_str(result)); return 1; } const char user_password = "MyVerySecretPassword123!"; // This is the sensitive input // Call the ECALL to generate the hash securely int ret = -1; result = generate_secure_hash(enclave, &ret, user_password, hashed_data, sizeof(hashed_data)); if (result != OE_OK || ret != 0) { fprintf(stderr, "Failed to call enclave function: %s\n", oe_result_str(result)); } else { printf("Host: Successfully processed sensitive data securely.\n"); printf("Host: Received secure hash: %s\n", hashed_data); // The original password was never exposed to the host OS during hashing. } // Terminate the enclave oe_terminate_enclave(enclave); return 0;
}

This demonstrates the fundamental “secure function execution” pattern where critical logic operates entirely within the isolated TEE.

Practical Use Cases: Where TEEs Shine

1. Confidential AI/Machine Learning Inference:Protect proprietary AI models and the sensitive data they process. For instance, a medical AI model could analyze patient data within an enclave without exposing either the model’s intellectual property or the patient’s private health information to the cloud provider or even the OS.
2. Blockchain and Cryptocurrency Security:Secure the execution of smart contracts, private key management, and transaction signing. TEEs can ensure that a blockchain node’s private key is never exposed to the host system and that smart contract execution is tamper-proof.
3. Digital Rights Management (DRM):Protect premium content. TEEs can be used to securely decrypt and render copyrighted video or audio content, preventing unauthorized copying or access by other software on the system.
4. Secure Multi-Party Computation (MPC):Enable multiple parties to jointly compute a function over their private inputs without revealing those inputs to each other. TEEs can significantly simplify and accelerate MPC protocols by providing a trusted execution environment for intermediate computations.
5. Secure Key Management and Secrets Storage:Store master encryption keys, API tokens, or other sensitive credentials in a hardware-backed secure vault, inaccessible to the broader system. This significantly enhances the security of secret management systems.

Best Practices for TEE Development

• Minimize the Trusted Computing Base (TCB):Only put absolutely essential code and data into the enclave. The smaller the TCB, the smaller the attack surface. Every line of code inside the enclave must be meticulously reviewed.
• Strong Attestation:Always perform remote attestation to verify that the enclave is running on genuine hardware, is the expected version, and hasn’t been tampered with, before sending sensitive data to it.
• Secure Communication:Encrypt all data exchanged between the host and the enclave, even though the enclave itself provides isolation. This protects data in transit over shared memory.
• Careful Data Marshalling:Explicitly define and validate all data marshalled between the host and the enclave. Malicious input from the host can still exploit vulnerabilities in enclave-side parsing.
• Handle Enclave Exits Gracefully:TEEs are not immune to software bugs. Plan for error handling, enclave crashes, and recovery strategies that don’t compromise security.
• Regular Patching and Updates:Keep TEE SDKs and hardware firmware updated. New vulnerabilities in TEE implementations are discovered, and vendors release patches.
• Avoid Dynamic Code Generation/Loading:The static nature of enclaves is key to their security. Avoid generating or loading code dynamically within an enclave, as this complicates attestation and security guarantees.

Common Patterns in TEE Application Design

• Data Processing Pipeline:Sensitive data enters the host, is passed to the enclave for secure processing (e.g., encryption, AI inference, hashing), and then the processed (often anonymized or encrypted) result is returned to the host for further, non-sensitive operations.
• Secure Service Offload:A specific, security-critical service (e.g., a cryptographic key server) runs entirely within an enclave, exposing only a strictly defined API to the rest of the system or network.
• Confidential Containers/VMs:Entire containerized applications or virtual machines can run within TEEs (often called confidential containers or confidential VMs), providing a broader isolation boundary for legacy applications or those requiring a full OS environment.

By adhering to these practices and understanding common design patterns, developers can harness the formidable power of TEEs to build a new generation of truly secure and privacy-preserving applications.

TEEs vs. Traditional Security: Choosing the Right Shield

When architecting secure systems, developers have a spectrum of tools at their disposal. Understanding where Trusted Execution Environments fit, especially in comparison to more traditional security approaches, is crucial for making informed design decisions.

TEEs vs. Software-Only Encryption

• Software-Only Encryption:This is the baseline. Data is encrypted at rest (on disk) and in transit (over networks). Tools like AES-256 for files, TLS for network communication, and database encryption are common. The keys for these operations are typically held in software memory, making them vulnerable to attacks that compromise the operating system, hypervisor, or even sophisticated malware.
  • Pros:Easy to implement, widely supported, flexible.
  • Cons: Data is vulnerable while in use. If an attacker gains root access or compromises the application process, they can dump memory and potentially access unencrypted data or cryptographic keys.
• Trusted Execution Environments (TEEs): Extend protection to data in use. Data and code within an enclave are protected from inspection or tampering by any software outside the enclave, including the OS, hypervisor, and even firmware. The cryptographic keys and computations remain isolated within the hardware-backed secure boundary.
  • Pros:Offers the highest level of confidentiality and integrity for data and code during computation, even against privileged software attacks. Enables “confidential computing.”
  • Cons:Higher development complexity, potential performance overhead, limited memory/resource capacity within the enclave, reliance on specific hardware.

When to use TEEs over software encryption:When the threat model includes a malicious or compromised OS/hypervisor, or when regulatory compliance demands protection of data and code during processing (e.g., medical records, financial transactions, proprietary AI models).

TEEs vs. Hardware Security Modules (HSMs)

• Hardware Security Modules (HSMs):Dedicated physical devices (or virtualized cloud services) designed to perform cryptographic operations and store cryptographic keys securely. They are highly tamper-resistant and often FIPS 140-2 certified. HSMs excel at key generation, storage, and cryptographic acceleration.
  • Pros:Extremely secure for key management and cryptographic operations, high certification levels, tamper-resistant.
  • Cons: Primarily designed for key storage and limited cryptographic functions, not general-purpose code execution. Expensive, complex to integrate, and often network-attached.
• Trusted Execution Environments (TEEs): Provide a secure environment for general-purpose code execution and data processing, in addition to secure key management. They are designed to protect computation itself, not just the keys that enable it.
  • Pros:Secure general-purpose computation, protection against privileged software attacks, closer integration with CPU.
  • Cons:May not have the same level of physical tamper-resistance or certification as a dedicated HSM for pure key management, lower performance than standard CPU execution for complex tasks.

When to use TEEs vs. HSMs:

• Use TEEs when: You need to protect code and data during complex computation from a compromised OS or hypervisor. Examples: Confidential AI inference, secure smart contract execution, multi-party computation.
• Use HSMs when: Your primary need is extremely secure key generation, storage, and basic cryptographic operations (sign/verify, encrypt/decrypt) without the need for executing complex application logic. Examples: Root CAs, master key storage, secure boot.
• Often, they are complementary:TEEs can leverage HSMs for storing their own sealing keys or for high-assurance master key management, combining the strengths of both.

TEEs vs. Virtual Machines (VMs) and Containers

• VMs/Containers:Provide isolation at the software level. VMs abstract hardware, running guest OSes isolated from the host OS (but not from the hypervisor). Containers isolate processes from each other and the host OS kernel (via namespaces and cgroups).
  • Pros:Excellent for resource isolation, multi-tenancy, and managing software dependencies. Widely adopted, flexible.
  • Cons: No protection against the underlying host OS or hypervisor.A compromised hypervisor can inspect or tamper with any VM. A compromised host OS can inspect or tamper with any container.
• Trusted Execution Environments (TEEs): Provide hardware-enforced isolationeven from the host OS and hypervisor. While confidential VMs or confidential containers use TEEs to secure the guest VM/container from the host, the TEE itself is the fundamental isolation primitive.
  • Pros: Guarantees code and data confidentiality and integrity from all privileged software above the TEE hardware.
  • Cons:Granularity of protection is at the enclave level, not typically for full OS/VM. Higher overhead when integrating an entire OS within a TEE compared to traditional VMs.

When to use TEEs vs. VMs/Containers:

• Use VMs/Containers when:You need software-level isolation, resource management, and portability, and your threat model does not include a malicious hypervisor or host OS.
• Use TEEs (or Confidential VMs/Containers that leverage TEEs) when:You require proof that your application or data cannot be accessed or tampered with by the cloud provider, administrator, or any other software on the system, regardless of its privilege level.

In essence, TEEs offer a new layer of security, creating a truly private and verifiable execution space for critical code that was previously unavailable. While they introduce development complexities and specific hardware dependencies, their unique ability to protect data in use makes them indispensable for the most sensitive applications in an increasingly untrusted world.

Forging the Future: Your Role in Secure Computing

Trusted Execution Environments represent a pivotal shift in how we approach software security, moving beyond traditional perimeter defenses to establish hardware-backed trust directly at the heart of computation. We’ve explored how TEEs create unbreachable vaults for critical code and sensitive data, safeguarding them from even the most privileged software. From understanding their foundational concepts to navigating essential SDKs and applying them in real-world scenarios, the journey into TEEs empowers developers to build applications that are not just robust but fundamentally trustworthy.

As the demand for data privacy and intellectual property protection intensifies across cloud, edge, and AI domains, TEEs will become an increasingly non-negotiable component of secure system design. For developers, embracing this technology now means equipping yourself with a crucial skill set that defines the next generation of secure application development. By prioritizing secure coding practices, diligently performing attestation, and minimizing your trusted computing base, you can contribute to a future where code operates with unprecedented confidence, fostering a truly confidential digital world.

Unlocking TEE Insights: Your Quick Guide to FAQs & Terminology

Frequently Asked Questions about Trusted Execution Environments

1. Are TEEs truly unhackable? No system is 100% unhackable. TEEs provide a very high level of security by isolating code and data from privileged software attacks (OS, hypervisor). However, they can still be vulnerable to physical attacks, side-channel attacks (if not mitigated correctly), or newly discovered hardware vulnerabilities. Developers must still write secure code within the enclave.
2. What’s the performance overhead of running code in a TEE? There is typically some performance overhead, but it varies significantly depending on the TEE platform, the nature of the code running inside (CPU-bound vs. I/O-bound), and the frequency of calls between the host and the enclave. Intel SGX, for example, might introduce a 5-20% overhead for CPU-intensive tasks, and higher overhead for frequent ECALLs/OCALLs due to context switching. Modern TEEs are continuously optimized to minimize this.
3. Which TEE platform should I choose (e.g., Intel SGX vs. ARM TrustZone)? The choice depends heavily on your target environment. Intel SGX is prevalent in data centers, cloud environments (e.g., Azure Confidential Computing), and high-performance computing. ARM TrustZone is dominant in mobile, IoT, and embedded systems. For platform-agnostic development, the Open Enclave SDK offers a unified API that supports both, simplifying the decision.
4. Can I debug inside a TEE enclave? Yes, but it’s more complex than debugging a standard application. TEE SDKs usually provide specialized debuggers or modified GDB versions. Debugging often requires enabling a “debug mode” for the enclave, which lowers its security guarantees and should never be used in production. This highlights the importance of thorough testing and static analysis.
5. How do TEEs prevent physical tampering? TEEs primarily protect against software attacks. While some TEEs (like some ARM TrustZone implementations for embedded devices) might incorporate physical tamper detection or resistance, the core TEE concept focuses on isolation from privileged software. For robust physical protection against sophisticated adversaries, TEEs are often combined with Hardware Security Modules (HSMs) or physical security measures.

Essential TEE Technical Terms

1. Trusted Execution Environment (TEE):A hardware-backed, isolated processing environment that ensures the confidentiality and integrity of code and data loaded within it, protecting them from external software, including the operating system and hypervisor.
2. Enclave:The specific, isolated region of memory and CPU state within a TEE where sensitive code and data reside and execute. It’s the “secure vault” itself.
3. Attestation:A cryptographic process by which a remote party can verify that a specific, genuine TEE is running the expected, untampered code. This is crucial for establishing trust before sending sensitive data to an enclave.
4. Host Application:The non-secure part of a TEE-enabled application that runs outside the enclave. It’s responsible for managing the enclave, loading code into it, and communicating with it.
5. ECALL (Enclave Call):A function defined within an enclave that can be securely invoked by the host application to perform operations inside the trusted environment. Data passed via ECALLs is marshalled securely.

Published on November 20, 2025