Skip to main content

How does UKey Transfer keep data migration secure?

U
Written by UKey Wallet

UKey Security Architecture

UKey Transfer It is UKey Wallet an advanced secure communication component built into the client, designed for cross-end encryption migration of software wallet private keys 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 wallets involve complex interactions between the underlying physical security chip (SE) and the isolated execution environment, the data interoperability protocol on the relevant hardware side is under development and evaluation and will be deployed in future firmware and client updates.

1. Core security principles and architectural foundation

UKey Transfer's security architecture is built on the following two core technical principles:

  • 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. Throughout the data transmission link, No third-party node, including the UKey official server, can decrypt or snoop the clear text of the data.

  • Relay server zero-knowledge proof (Zero-Knowledge): UKey The official server only serves 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

To defend against 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 across 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 not be sent to any external network or server.

3. Mixed injection of multi-source keys

The symmetric key ultimately used to encrypt the private key data is generated by the following factors:

  • Local environment entropy source: The current lock screen authorization 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 authorization and two-way physical verification

  • Terminal lock screen authentication: When triggering the private key export or reception 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 begins, the sender and receiver screens will simultaneously display a 6-digit verification code generated by the link parameters. The user must visually check that the numbers on both ends are completely consistent before authorizing the transmission. 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 session end.

  • Illegal connection preemption elimination: If an attacker intercepts the pairing code and tries 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 rights absolutely belong to legal physical terminals.

4. Advanced Security and Private Deployment Options

For users with higher privacy requirements, the following advanced data isolation solutions can be used:

  • Private relay server deployment: Users can deploy the UKey Transfer server on a private cloud or local server that they can control, and configure it in the client [Custom Server], achieving completely autonomous and controllable signaling routing.

  • LAN physical isolation and mutual transmission (under development): In a future iteration, UKey Desktop will support serving as a signaling relay for a local area network (LAN). By then, Mobile devices within the same LAN can complete private key migration while completely disconnected from the public Internet, achieving true physical-level network isolation transmission.

Did this answer your question?