Mechanism Paper
About the Hyphen Key Management Mechanism
Last updated
Was this helpful?
About the Hyphen Key Management Mechanism
Last updated
Was this helpful?
There’s no existing wallet that satisfies User Experience, Recoveriness, and Security.
User Experience (UX): Creating and connecting a wallet should be easy and hassle-free as the user experience on Web2.
Recoveriness: When a user loses the primary mean of accessing the wallet, it should provide a secondary method to recover access.
Security: The private key should be managed and stored in a secure manner to prevent being stolen.
Currently, there are not many resources when developing a mobile app on Flow. Most of the resources are focused on building on the web and it’s hard to find the libraries/resources for mobile development.
In the Flow account system, the account and the key are decoupled, so it is possible to add or detach multiple keys into an account to use it as a multi-signature account, or each key can have a different cryptographic signature scheme.
Interestingly, Flow is the only chain that supports the NIST P-256 (secp256p1) curve, which is also the only curve that is supported by TEE in both Android and iOS. This characteristic encourages optimizing a wallet system for mobile user experience.
We introduce a Hyphen: A secure key management scheme leveraging Flow’s native account system and TEE in mobile devices.
In MEOW, a user account is set up as a multi-sig account with three types of keys: device key, server key, and recovery key. At least 2 keys are required to send a transaction.
The device key is stored safely on the mobile device’s secure hardware chip: TEE. it can be seen as utilizing users’ mobile devices as a cold wallet. to improve the recoverability and user experience, the server key and recovery key are used: the server key is stored on the Hyphen's server, and the recovery key is stored on the user’s cloud storage. with the keys distributed each different place, the maximum level of security can be assured while sacrificing any user experience.
App: A client app uses Hyphen.
User: The user using the app. The owner of the account.
TEE (Trusted Execution Environment): An isolated hardware for secure operations. When it’s used for public key cryptography, it allows signing or verifying a signature while keeping the private key inside of the hardware.
Server Key: One of the default keys of a Hyphen account, which is stored on Hyphen's server.
Cloud Key: One of the default keys of a Hyphen account, which is stored on the user’s own cloud storage such as iCloud Keychain, Google Cloud, etc.
Device Key: A key stored in TEE in a user’s mobile device.
The key is isolated from the mobile OS using a specialized hardware chip to protect it from any security threats, and an app can only request to sign/verify a transaction.
Hyphen achieves a form of hybrid custody by mixing self-custodial keys and a custodial key for an account. An account is composed of three types of keys: Server Key, Device Key, and Recovery Key.
The server key is a custodial key that is hosted by the Hyphen server. Device Keys are self-custodial keys safely stored in the TEE of users’ mobile devices. The recovery Key is a backup key used in case of device loss or app uninstall.
To send a transaction, at least 2 keys are required. This scheme maintains perfect checks and balances in terms of security: even if any of the keys is being stolen or used maliciously, the account access is still protected.
After the initial sign-up process (e.g. Social Login), an N-of-2 multi-sig account is created with three keys.
Diagram 1. Initial Key Distribution on Account Creation. Every key’s weight should be set as same.
Recovery Key: stored on the user’s cloud (e.g. Apple iCloud, Google Cloud).
Server Key: stored in the Hyphen server. often mentioned as a custodial key.
Device Key: stored in the TEE of the user’s mobile device. never accessible on the outside.
To send a transaction, it is required to reach at least a quorum of 2 keys. So even if a key is being stolen by malicious actors, the account is safe because they still need one more key to get control. However, it’s not feasible because these keys are stored in different locations.
By default, the current device’s key and the server key are used to sign a transaction. Using the device key requires biometric auth from a user (e.g. Face ID, Touch ID), and the server key requires JWT auth to the Hyphen server, which is internally handled by Hyphen SDK.
Diagram 2. Illustrates a process of signing & sending a transaction in Hyphen.
As a user uses more apps using Hyphen with more devices, more device keys can be created and registered into the account. If a user uninstalls an app or lost a device, they can revoke the access of the device key to the account.
Hyphen provides session-management features just like the familiar Web2 services like Google, Facebook, and Whatsapp.
To sign in from another app or another device, a new device key should be created and added to the account. First, the app needs to let the user sign in with the login methods provided by Hyphen. After signing in, the app will be authenticated to the Hyphen server, thus getting access to the server key. However, since adding the key requires sending a transaction, which requires at least 2 keys— the app needs another device’s help since one is not enough.
This is where the 2FA (2-Factor Authentication) comes in. The app (new device) requests 2FA to the user’s other devices, and the user authorizes it on the other device. The Hyphen server acts as a relayer that relays the 2FA request/responses.
When a user loses a device or tries to sign out from an app, the device key should be revoked from the account. A transaction should be sent to remove the device from the account’s key list.
Although the key is named as “device key”, it’s actually app-specific: since the Android and iOS sandboxes each app’s storage, it’s no exception for TEE keystores. Even on the same device, the device key should be created per app installation and can be reset if:
the user deletes the app
the user changes biometric auth information (e.g. on iOS, adding a new finger to Touch ID)
the limitation of the device key is that it has a shorter lifespan, as you can see. normally this would be not a good characteristic of be crypto wallet— so we leverage it with the multi-sig scheme and, the recovery key.
When a user loses access to the account, for example when they lost all devices registered or device keys are being reset, Hypen provides a password-reset-like-UX to recover the account.
The recovery key is a backup key used in the case when the user loses access to the account. It’s stored on the user’s own cloud storage so the user can access it anytime. Using the recovery key and the server key, a user can send the transaction to register a new device.
<aside> <img src="/icons/cloud-yes_lightgray.svg" alt="/icons/cloud-yes_lightgray.svg" width="40px" /> Types of Cloud Storages The Cloud storage can differ by the platform:
Apple: iCloud Keychain
Android: Google Cloud </aside>
Without the recovery key, there’s a risk of the user being lost access to the account if they only have one device registered and lost the device since the multi-sig requires at least 2 keys.
But if we have another backup key, the user can still maintain access through the key and the server key, because both are stored in a remote location. For checks and balances, the recovery key is stored on the user’s own cloud account.
Thanks to the multi-sig, it’s safe to store the recovery key on the cloud. Mobile wallets storing the private key on the cloud are often criticized that it’s unsafe. But it's safe even if the recovery key gets hacked— because the recovery key alone, which is just one of the keys, is not enough to send a transaction.
For some apps, adding a step in onboarding to create a recovery key can be a burden. MEOW offers a variety of options for the apps:
With Cloud Key: Recommended.
No Cloud Key: Not recommended in terms of recoverability, but could be the best in terms of initial onboarding UX. An app can remind users to create the backup key later.
Example: Rainbow Wallet nudges the user to back up their key on iCloud later.
The recovery key acts a similar role to the seed phrase. Both are used as backup methods when a user lost their key— but unlike the seed phrase, it’s more secure and enables easy UX for the user. Here’s the comparison:
When a user onboards
Write down the seed phrase, and double-check to make sure that they wrote it correctly.
Connect iCloud / Google Cloud with a click of a button.
Where it is stored?
Offline recommended, but any uncautious user can keep it online (e.g. Memo App, 1Password, …)
Encrypted on User’s Cloud
What happens when it’s stolen?
The access of accounts created with the seed phrase is being exposed to the hacker.
Nothing. To get access, the hacker also needs to hack the Hypen server to get the server key.
How to cope with the hacks?
Move all assets in the account immediately into the new account.
Just revoke the lost key and reissue a new one.
A user can take full control of his/her own account by following methods. Note that these methods are mutually exclusive: one or more methods can be applied by the user.
Hosting a server key on the Hypen server makes Meow “hybrid custody”. But since the user has the majority of keys, it can be made self-custody by just revoking the server key.
After revoking the server key, the user will always need to do 2FA every time they send a transaction because two keys are required.
The best situation in the crypto world is having their own personal wallet. Of course, the user could barely care about crypto things like self-sovereignty at the beginning, but as time flies and the user’s asset grows, the user might think that it’s time to switch over a safe, personal wallet owned by themselves.
Luckily, Flow has the capability of account linking, enabling an account to be linked to another account as the parent account. The parent account is able to control the child including its assets.
