Transaction Key Segmentation for Secure Multi-User Access
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Traditional permission management schemes in e-commerce and asset management are insecure and inconvenient due to the reliance on constant user keys, leading to delayed or stopped transactions if a user loses or refuses to use their key, and are vulnerable to improper permission usage.
Innovation Solution
A method and device for key management that splits a transaction key into sub-keys, each encrypted with a user's public key, requiring collaboration among a group of users to restore the key, ensuring security and reliability by setting a minimum number of users required for restoration and allowing asynchronous distribution.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If multiple users sequentially sign the same transaction with their respective keys, then security is improved and key leakage is prevented, but the transaction process becomes lengthy and inefficient
Solution Approach 1:
The transaction key is segmented into multiple sub-keys, each held by different users. Instead of requiring sequential signing operations, the system divides the cryptographic key itself into parts that can be independently stored and later recombined, eliminating the time-consuming sequential process while maintaining security through distributed key custody
Solution Approach 2:
The transaction key is pre-split into sub-keys and distributed to users before the transaction occurs. This preliminary key preparation allows users to have their sub-keys ready in advance, eliminating the need for real-time sequential signing operations and significantly reducing transaction processing time
2Ease of operation
If each user holds their own key for permission management, then individual control is maintained, but transactions may be delayed or stopped if a user loses or refuses to use their key
Solution Approach 1:
The system prepares for potential key loss or user unavailability by pre-distributing sub-keys to multiple users and storing backup sub-keys on the management device. This cushioning mechanism ensures that if one user loses their sub-key or refuses to cooperate, the transaction can still proceed by using sub-keys from other users or the backup storage, thereby maintaining transaction completion reliability
Solution Approach 2:
The management device serves as an intermediary that stores backup sub-keys and facilitates key restoration. When a user loses their sub-key, the management device mediates the restoration process by providing backup sub-keys that can be combined with other users' sub-keys to reconstruct the transaction key, ensuring continuous operation without transaction delays
3Ease of operation
If users keep constant keys for a period of time, then key management is simplified, but the probability of key decryption increases
Solution Approach 1:
The constant transaction key is segmented into multiple sub-keys distributed to different users. Even if one sub-key is compromised, the segmentation ensures that the complete transaction key cannot be reconstructed without multiple sub-keys, significantly reducing the impact of any single key decryption attempt while maintaining operational simplicity
Solution Approach 2:
Different sub-keys have different security characteristics and are held by different users with different security practices. This local quality differentiation means that compromising one user's sub-key does not compromise the entire system, as each sub-key provides only partial access and the security strength varies locally across different key holders
Data Source
Figure 1
Figure 2
Figure 3
AI summary
The present disclosure provides methods and devices for key management. In one example, a method of key management comprises: obtaining, at a user device, a number of users in a group of users and a minimum number of users for restoring a transaction key; randomly generating the transaction key; splitting the transaction key into a plurality of sub-keys, the number of sub-keys being the same as the number of users; and sending the plurality of sub-keys to a management device, each of the plurality of sub-keys being encrypted with a public key of a user corresponding to a sub-key.