Security
At Openfort, safeguarding the data and digital resources of your users is our utmost concern. We understand the crucial role we play in supporting our customers' applications and deeply value the trust placed in us.
Our system's design and infrastructure have been rigorously evaluated through multiple security assessments, audits, and penetration tests. Recognizing security as an ever-evolving challenge, we continually subject our systems to these evaluations to identify and remedy emerging vulnerabilities.
The process of embedding, maintaining, and testing security measures within your application is a significant endeavor. We dedicate ourselves to implementing industry-leading practices to protect your users' data and digital assets.
Highlighted below are key practices we employ:
Openfort Authentication Methods#
Openfort facilitates a variety of authentication techniques to confirm the identities of your users, including:
- Email verification using a one-time password (OTP) and password-based verification.
- Social account verification (Google, Apple, Twitter, Discord, Github) through OAuth2.0.
- Ethereum wallet ownership verification using Sign In With Ethereum (SIWE).
Token Issuance#
Following identity verification via any method mentioned, Openfort grants tokens for session authentication within your app.
- App Access Token: This token, helps ascertain user authentication within your app. It's a JSON Web Token (JWT), signed uniquely for your app, ensuring its authenticity and protection against forgery. This token helps your front and back end verify user authentication and originates from authenticated users. Its validity spans one hour, facilitating prompt session revocation and minimizing exposure risks.
User Data Encryption and Backup#
Openfort encrypts all database information at rest, with daily full snapshots and transaction log backups every five minutes, ensuring a week's worth of data restoration capabilities.
Traffic Encryption#
All network traffic employs TLS 1.2 encryption or higher, with HTTPS Strict Transport Security (HSTS).
API Security#
Access to Openfort's API for user data management requires authentication via the app's API secret.
Custody Model#
At Openfort, we provide the flexibility for games to choose the preferred custody model for their users' smart accounts. Our default solution is self-custodial (signer).
As a developer integrating Openfort, you can either have:
1. The Custodial Approach#
Being the custodial of the signer means having full control over the user's private key. With Openfort, you can store the private keys and send the signed payload to Openfort to redirect the transaction onchain. With this approach, you're custodial and required to comply with the necessary AML/KYC regulations (if applicable).
2. The Self-Custodial Approach#
In the self-custodial approach, the user's private key is not controlled neither by Openfort nor you. There are 2 options:
-
Option 1. Embedded Signer (Default) When a user creates an embedded signer, the private key is split into three shares using Shamir's Secret Sharing (SSS), and at least two of three shares are required to constitute the full private key.
-
Option 2. Third-party Signer Use an third-party signer provider to manage the signer, from KMS to different MPC (TSS, DKG and SSS) solutions.
Smart Contract Accounts#
Openfort smart accounts offer programmability directly at the wallet level. Custodianship of these smart accounts depends uppon how the signer that "owns" the wallet is managed.
Openfort Embedded Signer#
Using MPC technology, a shard of the key is generated in an isolated iframe, which manages the user's private key and handles wallet operations. The architecture of these wallets comprises three pivotal components:
- Openfort API: This component is responsible for storing metadata associated with a user's wallet, such as the wallet's address. It's a foundational layer that links a user's identity with their wallet operations securely.
- Isolated iframe: A crucial element in ensuring the security and privacy of a user's private keys. The isolated iframe operates as a secure environment, managing the private key and executing wallet operations. This setup is pivotal because it keeps the private key confined to an in-memory state within the iframe, never storing it in a database or allowing it to persist beyond the session. This isolation also means the private key is protected from potential exposure or theft, as it's inaccessible to both the app's code and the Openfort SDK.
- Openfort SDK: Offers a high-level interface for applications to interact with the embedded signer seamlessly. It simplifies the integration process, allowing developers to incorporate wallet functionalities without needing to delve into the complexities of blockchain technology.
The design philosophy ensures that the wallet's private key is always under the user's control, aligning with the principles of self-custodial wallets. This means that neither Openfort nor any integrating application has access to the wallet's private keys, safeguarding user autonomy and security.
info
The isolated iframe operates as a secure environment, managing the private key and executing wallet operations. If you'd like to host your own iframe instance, please refer to the Advanced self-hosted documentation.
Key Management#
Openfort's approach to key management and wallet recovery is built on a foundation of security and user control. When a user sets up an embedded signer, the process involves:
- Generating a Public-Private Keypair: Utilizing a Cryptographically Secure Pseudorandom Number Generator (CSPRNG) to ensure randomness, the iframe generates a keypair. This process involves selecting 128 bits of entropy and converting them into a mnemonic using the BIP-39 standard, from which the public and private keys are derived.
- Private Key Splitting: To enhance security, the private key is divided into three shares using Shamir's Secret Sharing, a method for distributing a secret amongst a group of participants. The shares are:
- A Device Share, stored locally on the user's device within the iframe's storage.
- An Auth Share, encrypted and held by Openfort, retrievable via the SDK during login.
- A Recovery Share, encrypted with either user-provided entropy (like a strong password) or with automatic recovery.
info
Recovery is facilitated through a service known as Shield, which manages the recovery share. It's important to note that the authentication share is retained within Openfort.
Deployment Options: You can either use the self-hosted or the managed Shield service.
Managed Shield service considerations
When Openfort manages Shield on your behalf, the primary security objective is to prevent Openfort from having control over both the authentication and recovery shares simultaneously. This precaution is essential to avoid the possibility of reconstructing the private key.
To accomplish this, when registering your project with shield, you will get an extra parameter called encryption_share. This parameter is one of the 2 shares of a splitted encryption key (that uses the same Shamir's Secret Sharing algorithm) that is used to encrypt the recovery share. This way, Openfort can't decrypt the recovery share without the encryption share.
This setup ensures that the full private key is reconstructed only in memory and never persists, requiring at least two of the three shares for reconstitution.
Wallet recovery#
Users are able to recover their private key even if they lose their device or if they lose access to your game. We support two methods of recoverability.
Offchain recoverability:
- If the user loses access to their device and is unable to retrieve their device share, they can combine their auth share and decrypt their recovery share to reconstitute the full private key.
- If the user loses access to your app and is unable to retrieve their auth share, they can combine their device share and decrypt their recovery share to reconstitute the full private key.
Onchain recoverability: Using social recovery to update the owner of the smart account. You can choose to set up Openfort is the entrusted guardian uppon account initialization as well as set up guardians that you help your users can recover access to their smart account. Lear more about social recovery.
Dev Accounts#
Developer accounts are tailored for the internal mechanics of your game. The signer is stored with Openfort KMS in order to manage the operations of the game. Each account can serve several purposes like escrow assets, being used to deploy contracts or simply as a treasury to transfer purchases of NFTs. The dev accounts are ERC2771 compatible to offer gasless transactions.
Architecture and Custody#
For developers and studios requiring managed wallets, Openfort leverages Google Cloud KMS to generate and securely store wallet private keys. This process allows for the automated creation of developer wallets, streamlining the management of in-game currencies, assets, and player transactions.
Key Management#
The KMS ensures that all cryptographic keys are stored securely, with stringent access controls and audit trails. This setup not only provides a high level of security but also complies with industry standards and regulatory requirements, ensuring that sensitive information is protected against unauthorized access.
The use of a KMS allows for robust key management and recovery processes. In the event of key loss or compromise, the KMS provides mechanisms for key recovery and rotation, minimizing the risk of asset loss and ensuring continuity of game operations.
Third-Party Reviews#
All of Openfort’s cryptographic libraries (notably around Shamir's secret sharing) are open-sourced and have undergone external audits.
Smart Contracts and Paymasters audited in Q4 2023. If you are a security researcher and would like to reach out to us, please do so using security@openfort.xyz.