UKey TransferIt is an advanced secure communication component built into the UKey Wallet client, specifically used for cross-end encryption migration of software wallet private key and sensitive data between different physical devices. This document aims to elaborate on the multi-layer cryptographic defense mechanism and secure communication protocol underlying this component.
Description of function scope:The current version of the UKey Transfer component is only open to data migration in software wallets. Since hardware wallet involves complex interactions between the underlying physical security chip (SE) and the isolated execution environment, the relevant hardware-side data interoperability protocols are under development and evaluation and will be deployed in future firmware and client updates.
1. Core security principles and architectural foundation
The security architecture of UKey Transfer is based on the following three core technical principles:
Completely open source and transparently audited:UKey adheres to the decentralized open source principle. The underlying source code of our client App and Relay Server has been made public in the official repository, and is subject to code review by the global network security community and developers, and security claims are verified with mathematical and cryptographic facts.
End-to-end encryption system (E2EE): All private key data to be migrated is encrypted and encapsulated at the highest level in the local memory of the sender device, and can only be decrypted and restored locally on the designated receiver device. In the entire data transmission link, any third-party node, including the UKey official server, cannot decrypt or spy on the plain text of the data.
Relay server zero-knowledge proof (Zero-Knowledge):UKey The official server only acts as the underlying network facility for "signaling relay" and "traffic routing" during the migration process. The server is completely unable to contact, access or know any key material or business data content.
2. Hybrid cryptography key derivation mechanism
In order to resist targeted attacks under extreme conditions, UKey Transfer uses multi-source heterogeneous data to jointly derive the final encryption key (Key Derivation Function, KDF). To decrypt data, an attacker must compromise multiple physical and cyber dimensions of defense simultaneously.
1. Elliptic Curve Dynamic Key Exchange (ECDHE)
Technical principles: At the beginning of the data migration session, the devices at both ends directly negotiate to generate a temporary, one-time shared session key through the ECDHE algorithm.
defensive advantage: Has forward security (Forward Secrecy). This key is generated entirely locally and is never transmitted in clear text over the network, making it unknown to the relay server. Even if the screen is maliciously recorded and the pairing code is leaked, the data in the transmission link cannot be intercepted and decrypted.
2. Asymmetric identification and pairing code routing
The long pairing code generated by the system is logically divided into two parts:
Route ID (first 10 characters): Only sent to the relay server as a public connection ID, used to locate two target devices in the network that require a handshake.
High entropy key material (last 40 characters): As the core high-entropy "salt" of local key derivation,Absolutely notbe sent to any external network or server.
3. Mixed injection of multi-source keys
The symmetric key ultimately used to encrypt private key data is generated by the following factors:
Local environment entropy source: The current lock screen approval credentials of the user device, the local pseudo-random number independently generated by this session, the globally unique identifier (UUID) of the App instance, and the built-in application underlying key.
Cloud collaborative entropy source: The independent session ID and server-side random number temporarily issued by the relay server for this connection.
3. Active Defense and Identity Verification Protocol
In addition to static cryptographic encryption, the system deploys strict active defense mechanisms and manual verification processes at the interaction layer.
1. Server-side risk control and prevention of brute force cracking
Request Rate Limiting: Implement strict frequency limitation on single device signaling requests at the network level (limited to a single request every 3 seconds), fundamentally blocking high-frequency scanning and flooding attacks.
Circuit breaker (Session Termination): The upper limit of connection verification failures for the pairing code is hard set to 10 times. Once the threshold is reached, the system will immediately and permanently invalidate the session and associated key resources.
2. Local approval and two-way physical verification
Terminal lock screen authentication: When triggering private keyexport or receiving process, the system forces the system-level biometric (Face ID/Touch ID) or device lock screen password to be called. Prevent the device from being physically hijacked by others and stealing assets when it is not locked.
6-bit hash digest verification line of defense: After the device is successfully paired but before data transmission starts, the sender and receiver screens will simultaneously display the 6-digit number verification code generated by the link parameters.Users must visually check that the numbers on both ends are completely consistent before transmitting approval.This design is the ultimate physical line of defense against man-in-the-middle attacks (MITM).
3. Credential invalidation and preemptive interruption
single validity: All pairing connection codes are one-time tokens and will be destroyed immediately after successful verification or the end of the session.
Illegal connection preemption elimination: If an attacker intercepts the pairing code and attempts to establish a false connection in advance, when the legitimate user's device (sender) initiates a real connection request, the underlying logic of the system will directly forcibly interrupt and kick out the previous illegal connection state, ensuring that control absolutely belongs to the legitimate physical terminal.
4. Advanced Security and Private Deployment Options
Thanks to the flexibility of the open source architecture, UKey allows users with extreme privacy requirements to adopt advanced data isolation solutions:
Private relay server deployment: Users can deploy the UKey Transfer server on their own controllable private cloud or local server by pulling the official open source server code. and configure it in the client【Custom Server】, achieving completely autonomous and controllable signaling routing.
LAN physical isolation and mutual transmission (under development): In future iterations, UKey desktop will support serving as a signaling relay station for a local area network (LAN). By then, mobile devices within the same LAN can complete private key migration while completely disconnecting from the public Internet, achieving true physical-level network isolation transmission.