Seed Splitting for Secure Cryptocurrency Key Backup
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current cryptocurrency key management systems face security threats due to the risk of private keys being stolen from Transaction Signing Server (TSS) memory, especially during key generation, backup, and restore operations.
Innovation Solution
The proposed solution involves splitting the Bitcoin or Ethereum master private key into multiple key shares and storing them on FIPS 140-2 Level 3 Hardware Security Modules (HSMs), implementing Seed Splitting and Firmware Extension for secure cryptocurrency key backup, restore, and transaction signing.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Ease of operation
If private keys are stored in TSS memory for transaction signing, then transaction signing capability is enabled, but security risk increases due to potential key theft
Solution Approach 1:
The master private key is divided into multiple key shares using secret sharing schemes. Each key share is stored in separate HSMs, so that no single point contains the complete private key. This segmentation prevents key theft even if one HSM is compromised, while still enabling transaction signing when sufficient shares are combined.
Solution Approach 2:
HSMs serve as intermediary devices that securely store key shares and perform cryptographic operations. The HSMs act as mediators between the key management system and transaction signing operations, providing a secure interface that eliminates the need to store complete private keys in TSS memory.
2Object-affected harmful factors
If master private keys are split and stored on multiple HSMs, then security against key theft is improved, but system complexity increases
Solution Approach 1:
The HSMs are designed to perform multiple functions: secure key share storage, key share combination, transaction signing, and key backup/restore operations. This multi-functionality reduces the need for separate dedicated systems for each operation, thereby managing complexity while providing comprehensive security.
Solution Approach 2:
The system uses configurable parameters such as threshold values for key share combinations and HSM identification. These parameters can be adjusted to balance security requirements against operational simplicity, allowing the system to adapt to different security needs without fundamental redesign.
3Ease of operation
If complete seed is exported from HSM for backup, then backup capability is enabled, but security risk increases due to exposure of master key
Solution Approach 1:
Instead of exporting the complete seed, the system exports only key shares that are encrypted and distributed across multiple locations. This segmentation ensures that no single backup location contains the complete master key, preventing key exposure risk while maintaining backup capability.
Solution Approach 2:
The system performs partial backup by storing only the necessary key shares rather than the complete seed. This partial action is sufficient for recovery purposes while minimizing the security risk associated with exposing master key material during backup operations.
4Object-affected harmful factors
If multiple key shares are required for recovery, then security against unauthorized access is improved, but recovery time increases
Solution Approach 1:
Key shares are pre-generated and distributed to multiple secure locations before recovery is needed. This preliminary action ensures that when recovery is required, the system only needs to retrieve and combine existing key shares rather than generate or search for them, significantly reducing recovery time while maintaining security through the multi-share requirement.
Data Source
AI summary
The Address Verification, Seed Splitting and Firmware Extension for Secure Cryptocurrency Key Backup, Restore, and Transaction Signing Platform Apparatuses, Methods and Systems (“SFTSP”) transforms contract deployment request, transaction signing request, key backup request, key recovery request inputs via SFTSP components into contract deployment response, transaction signing response, key backup response, key recovery response outputs. A contract deployment request message datastructure is obtained. Owner key identification parameters are determined. An owner public key is determined using the owner key identification parameters. An owner address is generated using the owner public key. A salt value is generated. A contract address for the smart contract is calculated as a function of the deployment factory address, the salt value, the contract code, and the owner address. An owner private key is determined using the owner key identification parameters and used to sign the contract address. A contract deployment data datastructure is provided.