# OpenSigner | Non-Custodial Wallet Key Management

> Open-source and non-custodial and self-hostable private key management.

## Docs

- [Deployment Scenarios](/security/deployment-scenarios): Due to the modular nature of the system, users can run or implement their own components.
Hybrid scenarios are possible where Openfort hosts some components while others are self-hosted.
- [Security Overview](/security/overview): The OpenSigner system is composed of multiple components that communicate over HTTP.
Communication includes sensitive data such as key shares or access tokens, therefore **it is crucial
to ensure communication is secured through TLS** and HTTPS is enforced.
- [Recovery Methods](/security/recovery-methods): The three supported recovery methods are *automatic*, *password* and *passkey* based recovery. Each has different security considerations.
Each refers to how the recovery share is encrypted, and how the user can access it.
- [System Integrity](/security/system-integrity): This page covers how to verify that OpenSigner components are authentic and haven't been tampered with.
- [Threat Analysis](/security/threat-analysis): This section covers potential attack vectors against OpenSigner components and recommended mitigations.
- [Introduction](/introduction/about): One of the most notable challenges in security is ensuring that a user—and *only* that user—has **continued** access to a secret, regardless of device loss, app reinstallation, or other life events.
- [Getting Started](/introduction/getting-started): After starting the components (for example, with `make run`), you can start using the OpenSigner service.
- [Setup](/introduction/setup): The project Makefile builds and runs all components through docker-compose.
- [Users](/introduction/users): The OpenSigner wallet key management components share one `user` concept, except for cold storage which expands on it.
- [Authentication](/components/auth): The authentication service is responsible for verifying users. The auth service,
hot storage, and cold storage all share the `user` concept. A user is a `uuid`,
and the owner of the data it has stored in the storages.
- [Hot Storage](/components/hot_storage): The Hot Storage component is used to store "hot shares": shares that are required each time an operation is performed with the private key
the "hot share" belongs to: log in, sign transactions, export the private key, and more.
- [iFrame](/components/iframe): The iFrame is the core client-side component that handles all cryptographic operations securely within the user's browser.
- [Cold Storage](/components/shield): The Cold Storage, or *Shield*, is where the cold share lives. It provides two main services:
- [OTP for Automatic Recovery](/components/cold_storage/otp): Shield supports One-Time Password (OTP) verification to add an additional layer of security when creating encrypted sessions.
- [Authentication Service API](/apis/auth_service)
- [Cold Storage API](/apis/cold_storage): Shield API returns various error codes depending on the type of failure encountered. Each error response includes an HTTP status code, an error code, and a descriptive message.
- [Hot Storage API](/apis/hot_storage)
- [Postman collection](/apis/postman): A Postman collection is available for testing the components. It runs
against the service created with the `make clean build run` command.
- [Recovering a Key](/actions/login): Before recovering a key, the user must call hot storage to retrieve their list of accounts and select the one to recover.
Once selected, pass the account UUID to the iFrame, which handles the recovery process.
- [Use the Key](/actions/operation): This section covers the signing use case.
After registering and logging into a device, the user can reconstruct their private
key in the iFrame and use it to sign data.
- [Creating a Key](/actions/signup): To create a new key with OpenSigner, users call the `create()` method on the iFrame.
The iFrame generates a new private key and splits it into three shares using threshold cryptography.
Two shares are distributed to hot storage and cold storage respectively, while the third share is stored locally in the localStorage.