Product

Key Import, Export and Archiving

Thibault de Lachèze-Murel
Christopher Grilhaut des Fontaines
September 20, 2024
Read time:

Secure key management is essential for compliance and governance. This post covers the risks and best practices for key import, export, and archiving, addressing critical security considerations and common vendor lock-ins that are often ignored.

In the dynamic landscape of digital asset management, the secure handling of cryptographic keys is paramount. At Dfns, we have introduced three essential features—key import, key export, and key archiving—to provide our clients with flexibility, security, and control over their assets, while combating vendor lock-ins that are crippling too many companies. These critical capabilities are not merely technical enhancements; they signify a fundamental shift in how security, regulation, and ownership are managed within the crypto ecosystem. In this blog post, we will explore the implications of these features and why they are crucial for compliance, administrative control, and governance.

Key import: Bring your own keys into Dfns

The ability to import private keys into Dfns’ infrastructure is a powerful tool for businesses and financial institutions managing digital assets on multiple blockchains. However, importing keys is not just a matter of convenience—it carries significant security and liability implications. 

At Dfns, we operate under a zero-trust architecture and discourage naive self-custodianship. Keys created outside of our security environment could have been compromised before their import, posing a risk to our clients and our platform. To mitigate these risks, we only allow key import for companies that comply with industry-standard security protocols. The analogy here is similar to the regulation of firearms: just as you cannot trade guns freely without oversight, wallet security should not be managed without stringent safeguards. Once a key is imported into Dfns, we share responsibility for its security, but clients must acknowledge that any pre-existing vulnerabilities remain their liability.

For those who prefer a higher level of security, we offer the option to create new keys within our platform and transfer assets from external wallets. This ensures that the keys are generated in a secure environment and are not subject to external risks. Importing keys may offer flexibility, but it is essential to understand the security trade-offs involved.

Key export: Stay in control over your keys

Key export lets clients move their private keys (or their end-users' keys in a non-custodial setup) out of Dfns. This allows them to manage the keys elsewhere or let end-users take control of their own keys. While this feature offers greater control, it also shifts the responsibility for securing those keys away from Dfns. Once a key is exported, it is marked as "archived" within our system, and we relinquish any control or liability over its security. This is a significant legal and operational shift: Dfns cannot be held accountable for the security of keys that were exported, as they are now outside our protective environment.

Just as with key import, we require clients to sign a letter of acknowledgment before exporting keys. This formal agreement ensures that clients understand the risks and responsibilities associated with managing keys outside of Dfns. Whether it’s for migrating to another provider, retaining full custody or in accordance with disaster recovery and business continuity plans (DRP/BCP), the choice to export a key should be made with full awareness of the security and risk implications. 

Key archiving: Why we don’t delete keys

In digital asset management, key deletion is a complex and often misunderstood process. At Dfns, we do not delete keys because true deletion can never be fully guaranteed. Because a key can easily be copied or duplicated, it is impossible to confirm that it has been entirely eradicated from all possible locations. Yehuda Lindell, in Coinbase’s whitepaper about MPC wallets, pointed out that while Coinbase claims to delete keys “on the fly,” this often means removing the key entry rather than the key itself. To claim a key is deleted without addressing potential copies or unknown duplications can be misleading and insecure.

Instead, we choose to archive keys. Archived keys are marked as inactive, securely stored, and cannot be used for transactions. This approach forces us to implement a robust zero-trust model for upstream and downstream actions, minimizing the risk of unauthorized access. It’s akin to handling nuclear waste—while it cannot be eliminated entirely, it can be secured in a way that makes it extremely difficult to access or misuse. By not deleting keys, we encourage a mindset of proactive risk management, security and governance, ensuring that all actions related to key management are transparent and controlled.

Introducing “Know Your Key” (KYK)

With the flexibility to import, export, and archive keys comes the responsibility to manage them effectively. We call this approach "Know Your Key" (KYK), a comprehensive framework for tracking the lifecycle of every key within the Dfns platform. KYK ensures that businesses have full visibility over who created a key, who accessed it, and what actions were taken, providing a cryptographic audit trail essential for operational efficiency, administrative clarity, and regulatory compliance.

For instance, if a key is imported from an external source, we document the origin and verify its integrity upon entry. If a key is exported, we record the exact time and recipient, ensuring that any movement is fully traceable. Note that each import and export action requires explicit customer authorization, secured by an additional private key that Dfns does not possess. This cryptographic safeguard prevents unauthorized key movements and maintains a high level of security. These measures are crucial not only for security but also for compliance with regulatory frameworks applied to information security such as the EU’s Digital Operational Resilience Act (DORA) and the U.S. Federal Information Security Modernization Act (FISMA).

Nota bene: Dfns supports a range of key types, including EC-based signing schemes like ECDSA, EdDSA, Schnorr and derivations like BIP and SLIP. However, there are limitations. We do not currently support key formats such as BLS, RSA, and certain “standard” derivation paths. Clients importing keys from external platforms need to be aware of these limitations. While we are continuously expanding our support for different key types, it is vital for clients to understand the scope of what is possible within our infrastructure.

In pursuit of key management standards for wallets 

Key import, key export, and key archiving are critical features for any wallet management system. These features provide businesses with the flexibility to manage their keys according to their specific needs while maintaining the highest levels of security and compliance. By following a zero-trust architecture and using NIST-compliant security measures (as outlined in NIST SP 800-57 Part 1-3), we promote a standard approach to key management in digital asset finance that, for example, actively avoids vendor lock-in.

Indeed, many wallet services, intentionally or not, lack essential key management features, creating vendor lock-ins that stifle industry growth by restricting interoperability. A truly robust product doesn’t need to trap customers and users; a genuinely secure one has a responsibility to offer key ejection capabilities to safeguard clients, even from the service itself. At Dfns, we acknowledge that any provider, including us, could pose a potential risk to the applications leveraging our technology. Our commitment is to protect our customers from these risks by empowering them with full control over their keys.

Another concern we have is that some so-called “non-custodial” wallet providers claim to offer key export and import functionalities but restrict them to end-users, preventing organizations from managing keys effectively. They disguise their lock-in strategy under the guise of “end-user protection.” This creates significant hurdles for applications using such providers (e.g., Web3Auth, Privy, Magic). When these applications encounter business, performance, or security issues and need to switch vendors, they must obtain consent from each user—a burdensome process that discourages migration. We believe in open systems that prioritize flexibility and choice, including both users and applications, enabling organizations and developers to deliver security, compliance, and a superior user experience without being tied to a single vendor.

Here are some key takeaways from the blog post:

  • Dfns only allows key import/export for companies meeting strict security standards to avoid risks similar to unregulated gun ownership.
  • Keys created within Dfns are secure and accountable; imported/exported keys fall outside our control, requiring a liability waiver from clients and/or end-users.
  • Dfns takes the risk of insider attacks seriously. Since key deletion can’t be reliably proven due to duplication risks, we archive keys instead. This allows us to manage access with a zero-trust approach, similar to handling nuclear waste. It also ensures we can provide access if regulators or law enforcement, with a judge’s approval, request it.
  • Dfns supports EC-based key types (e.g., ECDSA, EdDSA) but not all formats (e.g., BLS, RSA); important for clients planning on migrating key material from other vendors.
  • "Know Your Key" (KYK) framework provides comprehensive tracking and logs for key activity, ensuring security, compliance, and transparency.

Whether you are looking to import existing keys, export them for external management, or securely archive them, Dfns offers a robust, compliant, and secure solution that puts you in control of your digital assets. Ultimately, these features are not just about technical capability—they are about establishing a new framework for security, governance, and responsibility in the rapidly evolving world of digital finance.

Authors