Skip to main content
It is Turnkey’s approach that the safest place for key material is within the hardened secure enclaves, and within these enclaves alone. Our model guides using authenticators (or combinations thereof) of increasing sophistication, relating to the importance or consequences of a given action. For example, a full recovery of an organization may require multiple break-glass hardware authenticators, where a routine low-stakes action might only rely on an API key. The below options all involve some combination of authentication methods and policies. Both of these can be difficult to change later, so consider configuring your backup and recovery methods as early as possible.

​
Root user recovery

Touched on in the production checklist, the ‘native’ method of organization recovery in Turnkey is to configure multiple root users (recommended at least 3), who each have hardware authenticators such as biometric auth (TouchID on a MacBook) or a YubiKey physical passkey. With at least 3 root users, it is possible to set up a 2 of 3 root quorum which can bypass the policy engine and assert maximum authority in the case of disaster recovery - even when one root user may have lost access to their authenticator.

​
Sub-organizations

In a typical non-custodial/embedded wallet configuration, the same root user recovery approach can be effectively used. One could decide on a single ultimate recovery method, such as a passkey or email-based recovery, or a combination of multiple methods mirroring the previously outlined n of m.

​
Account based authenticators

An additional consideration for account-based authenticators (such as email or social login) is that these identity providers typically provide some form of account recovery as well. This can both work to help remove a single point of failure, but also introduce a risk of compromise were an attacker to gain access using this mechanism. Decide appropriately how account based authenticators fit your cybersecurity model.

​
Backup

Recovery is always our preferred approach, especially as a Turnkey organization can represent much more than just the wallets inside it. However, compliance with different security models demands flexibility and there are contexts in which exporting key material is appropriate. Wallets, wallet accounts, and raw private keys can all be exported securely, though these actions are typically highly controlled and require significant permissions on the order of a root quorum recovery. An embedded iframe is the preferred option for embedded wallets, as this ensures the key material, even while encrypted, passes directly between the clientside user and Turnkey’s servers. image.png The iframe typically exposes to the user in plaintext, though this is not a requirement. The target encryption key (TEK) can be any arbitrary P256 key, and it is possible (using PBKDF2) for this target key to represent a custom passphrase provided by the user. This can be implemented manually today, and Turnkey expects to offer it as a stock feature of the iframe shortly alongside the SDK option of saving to filesystem or secure cloud. For non-embedded wallets, scripted exports are also possible and use similar TEK-encrypted bundles.