---
id: secure_storage
title: Secure Storage
custom_edit_url: https://github.com/aptos-labs/aptos-core/edit/main/secure/storage/README.md
---
# Secure Storage

Secure storage provides a secure, persistent data store for sensitive data in the
blockchain. Examples of sensitive data here include information required for safety and
identity, such as cryptographic keys and consensus safety rules, as well as
run-time configuration data.

## Overview

For a design overview of secure storage, including the APIs, error types and policies, refer
to the secure storage specification:
[TODO(joshlind): publish the secure storage spec!]

## Implementation Details

This crate defines the secure storage API, made up of two separate Rust traits (interfaces):
- `KVStorage`: The KVStorage trait offers a key-value storage abstraction (e.g., to get
and set key-value pairs).
- `CryptoStorage`: The CryptoStorage trait offers a cryptographic-key based storage
abstraction for Ed25519 keys (e.g., key creation, rotation and signing).

This crate provides four different secure storage implementations, each of which implements
both `KVStorage` and `CryptoStorage`:
- `Github`: The Github secure storage implementation provides a storage backend using a
Github repository.
- `Vault`: The Vault secure storage implementation uses the Vault Storage Engine (an engine
offered by HashiCorp: https://www.vaultproject.io/). The Vault secure storage implementation
is the one primarily used in production environments by nodes in the blockchain.
- `InMemory`: The InMemory secure storage implementation provides a simple in-memory storage
engine. This engine should only be used for testing, as it does not offer any persistence, or
security (i.e., data is simply held in DRAM and may be lost on a crash, or restart).
- `OnDisk`: Similar to InMemory, the OnDisk secure storage implementation provides another
useful testing implementation: an on-disk storage engine, where the storage backend is
implemented using a single file written to local disk. In a similar fashion to the in-memory
storage, on-disk should not be used in production environments as it provides no security
guarantees (e.g., encryption before writing to disk). Moreover, OnDisk storage does not
currently support concurrent data accesses.

In addition, this crate also offers a `Namespaced` wrapper around secure storage
implementations. Using the Namespaced wrapper, different entities can share the
same secure storage instance, under different namespaces, providing an abstraction that
each entity has its own secure storage backend.

## How is this module organized?
```
    secure/storage/
    ├── github             # Contains the secure storage implementation based on Github.
    ├── src                # Contains the definitions for secure storage (e.g., API and error types),
                                as well as lightweight implementations for testing (e.g in-memory and on-disk).
    |── src/tests          # Contains the testsuite for all secure storage implementations.
    ├── vault              # Contains the secure storage implementation based on Vault, including the client
                                add fuzzing helper functions.
```