白皮书：基于 Android 通用设备的软件定义冷钱包架构

—— 离线签名、蓝牙交互与强制本地认证机制

摘要 (Executive Summary)

本文提出一种“软件定义冷钱包”（ Software-Defined Cold Wallet, SDCW ）架构。该架构旨在利用通用 Android 设备算力与安全特性，在无需购买昂贵专用硬件（如 Ledger/Trezor ）的前提下，构建一套高安全性的数字资产管理方案。

针对传统冷钱包交互痛点，本方案摒弃了繁琐的 USB 文件传输与受限于数据密度的二维码扫描，采用应用层加密蓝牙（ BLE ）作为交互介质。既保持了物理隔绝的安全性，又提供了接近热钱包的流畅用户体验。系统核心将交易流程严格解耦为“离线冷端”与“在线热端”，通过强制的“人在回路”（ Human-in-the-Loop ）认证机制，确保私钥永不触网。

1. 背景与动机 (Background & Motivation)

1.1 硬件钱包的“信任与成本”悖论

硬件钱包（ Hardware Wallet ）虽被视为行业金标准，但在普及过程中面临无法忽视的门槛：

• 高昂的拥有成本：主流硬件钱包售价通常在 $50 - $200 美元区间，对于入门用户或发展中地区用户是一笔不小的开支。
• 黑盒信任危机：绝大多数硬件钱包的固件（ Firmware ）甚至硬件设计（ PCB/SE ）是闭源的。用户必须无条件信任厂商未预留“后门”，且供应链在运输过程中未被物理篡改。

1.2 传统冷签名的“交互摩擦”

为了规避硬件钱包的成本与信任问题，现有开源社区出现了一些基于通用设备的冷钱包方案，但其交互方式往往严重牺牲了用户体验：

• **USB/SD 卡传输 (Sneaker-net)**：
  • 痛点：需物理插拔设备，依赖 OTG 转接头，操作繁琐且接口易物理磨损。
  • 风险：物理连接可能触发底层 USB 协议栈漏洞，或因自动挂载导致恶意软件跨设备传播。
• **二维码扫描 (Visual Air-Gap)**：
  • 痛点：数据传输带宽极低。面对复杂的智能合约交互或多签交易（ PSBT ），二维码密度过高导致难以识别，往往需要扫描动态生成的数十张连续二维码（ Animated QR ），体验极差。
  • 局限：极其依赖摄像头素质与环境光线。

1.3 本方案的突破：安全与便捷的平衡

本文提出的基于加密蓝牙的软件冷钱包旨在解决上述痛点：

• 零边际成本：利用用户闲置或旧款 Android 手机即可部署，无需购买专用设备。
• 完全开源可审：从应用层到通信协议全链路开源，不依赖专有硬件，任何人均可审计代码逻辑。
• 无感交互体验：利用低功耗蓝牙（ BLE ）传输数据，无需插线、无需对焦扫码。在保持私钥离线的前提下，提供如同“热钱包”般流畅的一键签名体验。

1.4 方案对比矩阵

2. 系统整体架构 (System Architecture)

2.1 角色定义 (Role Definition)

2.2 交互拓扑

通信仅通过应用层加密的低功耗蓝牙 (BLE) 进行，确保即使底层蓝牙协议栈存在漏洞，应用数据依然安全。

数据流向说明：

1. 热端构造交易数据，通过加密蓝牙发送至冷端。
2. 冷端在离线环境中解析交易，屏幕展示详情。
3. 用户在冷端进行物理确认（生物识别/密码）。
4. 冷端生成签名，将签名后的数据通过加密蓝牙回传至热端。
5. 热端将签名后的交易广播至区块链网络。

3. 威胁模型 (Threat Model)

3.1 信任假设

• 物理控制权：用户拥有离线设备的完全物理控制权。
• 系统纯净性：离线设备在安装应用前未被植入内核级后门。
• 热端零信任：假设联网设备已被恶意软件（ Malware ）完全控制，不仅能读取剪贴板，还能监听蓝牙流量。

3.2 攻击面防护范围

4. 核心安全原则 (Security Design Principles)

原则一：私钥易失性 (Ephemeral Key Usage)

• 磁盘加密：私钥在存储介质上必须经过高强度加密（ AES-256-GCM ）。
• 内存清除：私钥明文仅在签名函数执行的微秒级时间内存在于 RAM 中。一旦签名完成、应用切换后台或屏幕关闭，立即覆写（ Zero-fill ）内存区域。

原则二：强制物理在场 (Mandatory Physical Presence)

• 反自动化：系统严禁任何后台自动签名接口。
• **所见即所签 (WYSIWYS)**：冷端必须在独立屏幕上完整解析并展示交易详情（目标地址、金额、手续费），杜绝“盲签”。

原则三：深度防御认证 (Defense-in-Depth Authentication)

• 第一道防线：应用启动解锁（解密本地数据库）。
• 第二道防线：单笔交易签名认证（生物识别/密码）。
• 即使攻击者劫持了蓝牙连接发送了恶意签名请求，在无法通过物理生物认证的情况下，请求将被冷端拒绝。

原则四：会话完整性 (Session Integrity)

• 引入**防重放机制 (Anti-Replay)**：每个签名请求包含唯一的时间戳与随机数（ Nonce ）。
• 过期或重复的请求将被冷端直接丢弃。

5. 密码学实现规范 (Cryptographic Specifications)

本系统仅采用经过广泛验证的工业级标准算法，拒绝私有加密方案。

• 密钥派生 (KDF): Argon2id (推荐) 或 PBKDF2-HMAC-SHA512 (高迭代次数)，用于将用户口令转换为加密密钥。
• 数据存储加密: AES-256-GCM，确保机密性与完整性。
• 信道加密: 基于 ECDH (Secp256k1/X25519) 进行密钥协商，建立临时会话密钥，传输层使用 AES-GCM 封装。
• 数字签名: 支持 ECDSA (secp256k1) (Bitcoin/Ethereum) 及 EdDSA (ed25519) (Solana 等)。

6. 身份认证与生命周期 (Identity & Lifecycle)

6.1 冷启动与锁定

• 应用启动即处于“锁定”状态，内存中无敏感数据。
• 用户输入主密码或指纹后，仅在内存中解密“数据访问密钥”（而非直接解密私钥）。

6.2 灾难恢复

• 助记词标准：遵循 BIP-39 标准，支持 12/24 位助记词。
• 无后门设计：若用户遗失主密码，应用将无法解密本地数据，只能通过物理备份的助记词重置。这也意味着没有任何客服可以协助找回资产。

7. 局限性与风险声明 (Limitations & Disclaimer)

必须明确认知软件冷钱包的边界：

1. 通用 OS 的攻击面：Android 系统远比嵌入式安全芯片复杂，潜在的内核漏洞可能导致提权攻击。
2. 硬件隔离等级：虽然 TEE 提供了一定程度的隔离，但其安全性低于专用 Secure Element (SE)。
3. 适用人群：本方案适用于具备一定技术基础、需要管理中等规模资产或多签参与者。对于国家级对抗或极端高价值资产，仍建议配合多重签名（ Multisig ）或物理气隙（完全不使用蓝牙，仅使用二维码）方案。

8. 结论 (Conclusion)

本文提出的基于 Android 的软件冷钱包架构，通过严格的在线/离线职能分离、全链路加密以及强制生物认证，在通用消费电子设备上构建了一个高强度的安全环境。它打破了硬件钱包的高价与闭源壁垒，同时也解决了传统软件冷钱包在 USB 传输与二维码扫描上的体验痛点。以代码开源和架构透明为信任基石，为去中心化金融（ DeFi ）用户提供了一种兼具安全性、经济性与可访问性的资产管理新范式。