Ramper KMS Architecture V2

Scalable & user-friendly non-custodial wallet architecture

Ramper KMS architecture diagram

At Ramper, our mission is to make web3 accessible for the next billion users. To do so — we are reimagining the wallet sign-in experience. We believe everyone should be able to login & authenticate into blockchain applications seamlessly.

No seed phrases. No downloads. No passwords. It should be a single-click login experience.

To enable this experience, we built Ramper KMS V1, audited by CertiK. Today we are proposing V2 design.

Architecture

Summary

A non-custodial wallet gets created when a new user signs into a DApp via Ramper. The private key of the wallet gets encoded into two separate ciphers (split keys), and stored in the cloud via encryption. When a user needs to sign a transaction, a time-limited access token gets generated (tied to their email or SSO credentials) to retrieve the first key. The second key is fetched from a trusted execution environment once the user’s access token is verified. Here, the full private key gets reconstructed to sign the transaction details. It returns signed bytes to the user’s device. The user’s private key is never exposed outside a secure environment, including the user device, DApp, and Ramper.

Wallet creation

When a Ramper user is created, a number of things happen on the user’s local device (mobile & web browser):

1. A new hot wallet gets created (public address + private key) within the Ramper web application scope
2. The private key is then encoded into two separate ciphers (split keys) of the same size as the original private key via the Randomized XOR Cipher process
3. One cipher (Key A in the diagram) is sent to the third party KMS provider, where it is stored encrypted by an individualized HSM encryption key
4. The other cipher (Key B) is sent to the Ramper cloud storage, where it is stored encrypted by Ramper’s key

A few points to note regarding this process:

1. The two split keys (ciphers) are generated by a cryptographic algorithm, which means each of the ciphers does not contain any meaning information about the original key
2. Since these split keys are sent to each destination from the user device, Ramper never sees Key A that’s sent to the third party

Signing transactions

When a Ramper user needs to sign a transaction, the following operations are performed to facilitate it:

1. The user is authenticated by Ramper. A time-limited user access token is generated by a third party service provider (i.e. not owned by Ramper)
2. Split Key B is retrieved from Ramper to the user device
3. The transaction details to be signed, Key B, and the user access token are sent to the Transaction Sign Function
4. The Transaction Sign Function is a third party cloud serverless function run inside a Trusted Execution Environment (TEE), e.g. Intel SGX, AWS Nitro, ARM TrustZone
5. The Transaction Sign Function completes the following steps all within the secure TEE enclave:

• Verifies the user access token and the user identity
• Fetches Split Key A
• Reconstruct the original private key from Split Key A + B
• Signs the transaction details with the private key
• Returns the signed bytes

6. Once the signed bytes are returned to the user device, it can broadcast to the blockchain

As you can observe in the above description, the user’s wallet key is never exposed outside a secure environment, including any process run by Ramper *or* the user device. In addition, by leveraging multiple third-party secure services, Ramper can facilitate the non-custodial wallet functions while not creating a single point of vendor risk from the security point of view. It also means that no one at Ramper has a possible access path to the user’s private keys.

Third party KMS

The involvement of the third party (KMS runs on a separate Fortanix account) introduces the following characteristics:

1. There is a clear separation of encrypted user information and the method to decrypt it. It would take both of the industry leading cloud infrastructures (AWS and GCP) to be compromised, as well as our authentication system, for a user’s data to be exposed.
2. KMS is configured in a way that only the authenticated user is able to decrypt a given private key. This means Ramper, or anyone at the company, never has the ability to reconstruct a user’s private key, therefore being able to sign transactions on a user’s behalf. This makes our wallets “non-custodial”
3. There is no private key information stored on a user’s local device (such as Metamask or Terra Extension) or a piece of paper (mnemonic key) that need to be “recovered” in a loss event. If a user has forgotten their auth credential, one would be able to recover their account access through a familiar method, and as long as a user can authenticate their identity against Ramper, their private key will be there in the cloud.

One wallet per user — key difference vs. competitors

No DApps integrating Ramper SDK/API will ever get access to user private keys. This is achieved by (1) leveraging the browser’s single origin policy to create a web sandbox where DApps cannot access any authentication tokens, and (2) by utilizing a third-party trusted execution environment to sign transactions. Private keys are never exposed on local devices using Ramper’s KMS architecture.

You may notice that other cloud-based key management solutions create multiple wallets for the same user. Essentially every user gets a unique wallet per DApp they access. This is likely to minimize security damage in case of a hack. These solutions rely on DApps integrating their SDK/API to keep user keys safe. At Ramper, we’ve designed a system where the private key is simply never exposed to DApps (and us). This security enhancement enables Ramper to maintain a single wallet address per user across an infinite number of DApps.

Performance

One of our core areas of focus in implementing this design was performance. Our system supports up to 15+ million (signing) transactions per day with plans to rapidly scale this further.

Enhancements from MVP

MVP architecture: https://ramper.medium.com/ramper-architecture-f5106d8d7d5a

Multiparty computation

In the design phase of our non-custodial wallet architecture, we decided to split the original wallet private key into two parts (with the option to split further in the future for additional authentication methods such as local device fingerprint/faceId/hardware key). There are a few reasons why we wanted to take this path:

1. The cryptographic algorithm produces split keys that are meaningless by themselves (i.e. we aren’t splitting key “abcdef” into “abc” and “def”, each of which would then reveal information about the original key)
2. This keeps our architecture flexible and nimble such that

• If we detect any potential security issue, we can regenerate the split keys and “rotate” without having to change the original wallet key (i.e. effectively create a new wallet)
• We can add new authentication steps that have their own split keys for added security for the “advanced” users who may desire such a feature

Trusted execution environment

One of the notable differences between our v1 architecture and v2 is the use of the Trusted Execution Environment (TEE). This is an increasingly popular method of securing the data being processed (even from the actual machine running the process), which is required in sensitive/high value data processing environments, such as health care, PIIs and financial data.

The use of TEE for the transaction signing process means the user’s wallet key, as well as all the information necessary to reconstruct the key, never leaves the secure environment. The code to do so is audited and the process is guaranteed to be guarded from outsiders. Even in the event that the user device is severely compromised (trojan installed, device memory hacked and observed, etc), that device will never get to see the wallet key.

Reference: https://confidentialcomputing.io/wp-content/uploads/sites/85/2021/03/confidentialcomputing_outreach_whitepaper-8-5x11-1.pdf

Zero admin privilege

By leveraging multiple third-party services, Ramper introduces isolation of information and guarantees of access control, much like the need-to-know military strategy. For example, a third party access token issuer means no one at Ramper has the ability to pretend to be one of the users by *manufacturing* the user access token, because the encryption key to generate such a token lives outside of the Ramper-maintained infrastructure. Meanwhile, this third party service has no idea how the tokens are used, or has any other information necessary to access the users’ information.

The same applies to our TEE and KMS provider. The KMS stores only a split key, which is needed to reconstruct the wallet key but does not contain any meaningful information about the wallet key by itself. In addition, no one at Ramper has the ability to access these split keys stored in the KMS. The TEE has the code (audited to make sure the key doesn’t leave a given TEE instance) to reconstruct the wallet key, but no information to do so until the runtime.

The fact that all of these components are run and maintained by different entities, all rather security-focused organizations, give us the confidence that there is no single point of failure, from the attacking vector point of view. There is no one “big lock” someone can unlock to gain all the information. Moreover, the way we’ve designed out system means that even if one of these infrastructure pieces were to be compromised, the attacker will not have the ability to walk away with the users’ private wallet keys — and we’d simply regenerate the split keys afresh and rotate in response if we detect any such suspicion of a compromise, rendering the information the attacker extracted further worthless.