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

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

文档信息	内容
版本	v1.1
状态	公开技术提案 (Request for Comments)
日期	2025-12-01
许可	CC BY-SA 4.0

摘要 (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 方案对比矩阵

维度	本方案 (Android + BLE)	传统硬件钱包	传统 USB 冷钱包	二维码冷钱包
设备成本	低 (利用旧手机)	高 ($50-$200)	中 (需专用 U 盘/线)	低
代码透明度	100% 开源	多为闭源/部分开源	开源	开源
交互媒介	无线 (加密蓝牙)	USB / 蓝牙	物理插拔 (USB)	摄像头扫描
大数据传输	快 (支持大交易)	快	慢 (文件操作繁琐)	极慢 (需扫动图)
物理磨损	无	接口易磨损	接口易磨损	无
用户体验	流畅	一般	繁琐	累 (需手持对准)

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

2.1 角色定义 (Role Definition)

设备角色	网络状态	核心职责	安全边界
冷端 (Cold Host)	永久离线 (Air-gapped)	私钥生成、加密存储、交易解析、离线签名	极高：物理层断网，禁止任何网络权限
热端 (Hot Watcher)	在线 (Online)	构造未签名交易、广播签名数据、链上查询	低：假设环境已被污染，不可信

2.2 交互拓扑

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

数据流向说明：

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

3. 威胁模型 (Threat Model)

3.1 信任假设

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

3.2 攻击面防护范围

攻击类型	防护状态	说明
远程木马 (RAT)	✅ 已防护	冷端物理断网，远程攻击者无法触达。
中间人攻击 (MITM)	✅ 已防护	蓝牙信道采用 ECDH 密钥协商 + AES-GCM 加密，并绑定会话 ID 。
蓝牙协议栈漏洞	✅ 已防护	即使攻破蓝牙层，攻击者只能获得加密后的数据包。
侧信道攻击	⚠️ 部分防护	依赖 Android 系统层面的防护，软件层难以完全消除电磁/功耗泄露。
物理提取 (Evil Maid)	❌ 不在范围	若攻击者拆解设备并进行冷启动内存攻击，超出软件防护范畴。

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)

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

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

8. 结论 (Conclusion)

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

[白皮书] 一种无需专用硬件的钱包安全架构：离线签名、蓝牙交互与强制本地认证