为什么需要授权系统

我发现市面上有很多好用的工具和服务，它们都有一套机制来防止二进制文件被无限复制。仔细想想，这套机制本质上要回答三个问题：

1. 谁在用？ —— 绑定设备，防止一份 key 满天飞。
2. 用了多少？ —— 按通道数/用户数/功能模块计量。
3. 还能用多久？ —— 订阅到期自动降级，驱动续费。

带着这三个问题，我开始翻阅各家产品的授权方案。

一、业界典型方案速查

1.1 离线 License Key（早期方式）

代表产品：Windows XP、早期 Adobe CS

做法：用户输入一串序列号，软件在本地用算法校验是否合法。

• 优点：不依赖网络，部署简单。
• 缺点：一旦算法被逆向，注册机泛滥；无法控制同时使用的设备数量。

1.2 在线激活 + 硬件绑定

代表产品：JetBrains 全家桶、TablePlus、Sublime Text

做法：用户输入 key → 客户端采集本机硬件指纹 → 发送到服务端验证 → 服务端记录绑定关系并下发授权凭证。

• 优点：一份 key 只能绑定 N 台设备（Seat 限制），服务端掌握主动权。
• 缺点：离线环境需要"宽限期"机制，否则断网即停用。

JetBrains 的做法值得一看：单一安装包，未激活时为受限的社区版功能集，输入 key 后解锁全部功能。用户已经在产品内了，输入 key 就能升级，零摩擦——这种"in-product upgrade"模式转化路径最短。

1.3 滑动租期（Lease-based）

代表产品：HashiCorp Vault Enterprise、Keygen.sh

做法：客户端定期心跳，每次成功后服务端签发一个有时间窗口的"租约（Lease Token）"。租约到期前必须续租，否则功能降级。

• 优点：天然防离线破解——租期过了就得联网；服务端可以随时吊销。
• 缺点：实现复杂度高，需要处理网络抖动、时钟偏差、退避重试等工程问题。

综合来看，滑动租期实现成本最高，但安全性天花板也最高，尤其适合私有化部署场景。

1.4 云端 SaaS 计量

代表产品：Stripe、各类 API 网关

做法：功能本身跑在云端，按调用次数/月活/数据量计费。

• 优点：代码完全不在用户手里，无盗版问题。
• 缺点：不适用于需要私有化部署的场景。

1.5 开源核心 + 商业扩展

代表产品：GitLab CE/EE、Elasticsearch (Basic/Platinum)

做法：核心功能开源引流，高级功能（审计、SSO、集群）需要商业 License。

• 优点：社区生态与商业变现兼顾。
• 缺点：功能边界划分不当容易引发社区反感。

二、授权系统的核心技术点

了解了各类方案后，接下来看看这些方案背后的具体技术实现。

2.1 设备指纹采集

目的：给每台机器生成一个稳定的身份标识，重装系统后尽量不变。

我整理了常见的指纹来源，按稳定性分成三层：

我踩到的几个坑：

• 权限降级：Linux 下 /sys/class/dmi/id/product_uuid 权限为 0400 root:root，非 root 读不到。我发现需要降级到 dmidecode 命令作为 fallback。
• 无效值过滤：云厂商虚拟机可能返回全零 UUID（00000000-0000-0000-0000-000000000000）、Not Specified、None。如果不过滤，会导致不同机器被误判为同一台。
• Windows 注意：wmic 已废弃，应使用 PowerShell Get-CimInstance 或直接读注册表。
• 分层上报，不要本地混合哈希：一开始我想在客户端把所有特征混合成一个哈希值上报，后来发现这样服务端就无法做模糊匹配了——比如重装系统后 machine-id 变了但 SMBIOS UUID 没变，混合哈希就完全对不上。正确做法是分层原始上报，由服务端决定匹配策略。

2.2 非对称签名（Ed25519）

授权系统中广泛使用 Ed25519（一种椭圆曲线签名算法），我总结了三个典型用途：

• Lease Token 签发：服务端用私钥签名租期信息，客户端用服务端公钥验签——确保 token 未被篡改。
• 心跳防重放：客户端用实例私钥签名 nonce|seq|timestamp，服务端用注册时记录的公钥验签——确保请求来自真正的客户端。
• 局域网防撞：同网段设备用签名广播自己的身份，收到广播的设备验签后才处理——防止恶意伪造广播导致误报。

Ed25519 对比 RSA：签名速度快 10 倍以上、密钥短（32 字节）、无需选参数。缺点是生态较新，部分老系统不支持。

2.3 心跳与租期

以 Keygen.sh 为例的典型流程：

1
2

客户端定期发心跳 → 服务端验证后签发带 TTL 的 Lease Token
→ 客户端凭 token 运行 → 到期前必须续租

落地时有几个工程细节需要注意：

• 心跳抖动（Jitter）：在心跳间隔基准上叠加随机偏移（通常 ±10%），防止大量客户端同时心跳打爆服务端。
• 失败退避（Exponential Backoff）：心跳失败后按指数退避重试（间隔逐步加倍，设上限封顶），避免故障期间无意义的高频请求。
• 宽限期可配：不同客户的运维窗口不同，宽限期由服务端策略下发，客户端据此判断降级时机。
• 403 与超时必须分流：客户端收到 403（吊销/超限）应立即降级；收到超时或 5xx 应进入宽限期继续运行。如果混为一谈，服务端一宕机，全 fleet 就误降级。

2.4 时钟回拨防御

一种常见的攻击手法：把系统时间往回调，让已过期的租期"复活"。

防御方案——时钟水位（Clock Watermark）：

1. 每次心跳成功，服务端返回 server_time。
2. 客户端将 server_time 持久化到本地文件（水位值只升不降）。
3. 判断租期是否过期时，取 max(本地时间, 水位值) 作为当前时间。
4. 攻击者回拨本地时钟 → 水位值不变 → 租期仍按真实时间推进，攻击失效。

成本极低（一个文件），但只防回拨，不防快进。攻击者可以先将时钟拨快到远期 → 触发心跳获取一个远期 server_time 写入水位 → 再拨回正常时间——此时水位反而成了帮凶，客户端会以远期水位判定租期未过期。缓解方式：

• 限制单次水位跃升幅度：水位更新时校验 new_watermark - old_watermark 不超过合理上限（如两个心跳周期），超出则拒绝更新并告警。
• 水位写入绑定 nonce：只有服务端返回的 nonce 与本次心跳请求的 nonce 匹配时，才允许更新水位，防止用伪造响应写入任意时间。

2.5 防克隆机制

虚拟机整盘克隆是授权系统最难防的场景——所有磁盘数据（包括私钥、指纹文件）完全一致。

方案一：严格单调序号（seq > last_seq）

每次心跳携带一个严格递增的序列号。克隆体和原体各自递增，服务端发现同一 machine 的 seq 出现冲突（等值或回退）即熔断。

注意 seq 必须持久化到本地文件（而非仅内存），否则进程重启后 seq 从零开始，服务端会误判为克隆回退。关键细节：

• 先写后发（Write-Ahead）：客户端递增 seq 后，先持久化到本地文件，再发送心跳请求。如果发送后进程崩溃，重启后读到的 seq 已经是递增后的值，不会回退。
• 服务端容忍间隙：由于客户端可能持久化了 seq=N+1 但请求未到达服务端（网络丢包、进程崩溃），服务端应接受 seq > last_seq 而非严格 seq == last_seq + 1。间隙是正常的崩溃恢复现象，只有 seq <= last_seq 才标记为克隆/重放。
• 文件损坏恢复：这里有个容易做错的点——如果服务端在心跳失败时直接返回 last_seq 让客户端恢复，那克隆体也能用同样的方式拿到 last_seq 继续伪装，等于绕过了防克隆机制。正确做法：seq 文件丢失时，客户端应重新生成实例密钥对并走重新激活流程（对应上文 Case B：同硬件、新公钥）。服务端将其视为"重装/换绑"，重置 seq 和 nonce，旧实例的心跳会被拒绝。这样既恢复了合法客户端，又不给克隆体可乘之机——因为克隆体如果也走重新激活，就会产生两个不同公钥的实例竞争同一台硬件，服务端按 Case B 踢掉旧的。

方案二：内存态 RunID 局域网防撞

进程启动时在内存中生成一个随机 RunID（不写磁盘），通过组播向同网段广播。同一 DeviceID 但不同 RunID → 确认存在克隆分身。

两者互补：方案一在跨网段场景下有效，方案二在同局域网场景下能秒级检测。单独用哪个都有盲区，叠加后覆盖面才完整。

2.6 IP 漫游与并发分身识别

这里有一个容易出错的判断：IP 变了不一定是克隆，也可能是正常漫游。

正常场景：企业用户切换 VPN、双线出口，IP 变化但 seq 正常递增——应该放行。

异常场景：两个不同 IP 在短时间窗口内交替发心跳——需要区分是克隆分身还是用户切换网络（Wi-Fi → 蜂窝、VPN 切换等）。

判定逻辑（伪码）：

1
2
3
4

if IP 变化 && seq 严格递增 && 旧 IP 在窗口期内无并发请求:
    → 正常漫游（网络切换），更新 LastIP，放行
else if 两个 IP 在窗口期内交替出现（seq 各自递增但相互穿插）:
    → 并发分身（Split-Brain），触发暂停

注意窗口期的取值需要权衡：太短会把正常的网络切换误判为分身；太长则克隆检测不够灵敏。还需要考虑服务重启后 IP 变化的场景——结合 seq 连续性而非仅看 IP 变化。

2.7 服务端设备匹配状态机

当一台设备来激活时，服务端需要判断：是老设备回来了，还是新设备来了，还是克隆体。归纳为三个 Case：

1
2
3
4

Case A: 硬件指纹一致 + 实例公钥一致 → 原机恢复，直接续租
Case B: 硬件指纹一致 + 实例公钥不同 → 重装系统，走换绑流程
         （重置 seq 和 nonce，旧实例下次心跳收到 REBOUND_ELSEWHERE）
Case C: 全新硬件 → 校验 Seat 上限，未满则创建新记录

Case B 有个容易忽略的细节：换绑时必须重置 LastSequenceID = 0 并生成新 Nonce。否则新系统首次心跳（seq=1）会被旧的 last_seq 阻拦，导致合法重装后无法使用。

2.8 完全离线（Air-Gapped）激活

政企内网有一类极端场景：客户机永远不出网，心跳和租期机制全部失效。JetBrains 和 Keygen 都有对应的离线激活方案，核心是"文件交换式"激活：

1. 客户端生成包含设备指纹的激活请求文件（JSON 或加密包）。
2. 运维人员将请求文件拷贝到能联网的机器，上传到授权服务端。
3. 服务端校验后签发离线授权文件（包含 Lease Token + 有效期 + 签名）。
4. 运维人员将授权文件拷回客户机导入，客户端用内嵌公钥验签后启用。

离线授权的有效期通常较长（如一年），到期后需要重新走一遍文件交换流程续期。缺点是无法实时吊销——一旦授权文件签发，在有效期内即便服务端撤销了 License，客户端也无从得知。折中方案是缩短离线授权有效期并配合定期巡检。

这是私有化部署最容易撞墙的场景，文章前面讨论的心跳、防克隆机制在纯离线环境下大部分退化为依赖物理管控（如 USB 加密狗、硬件绑定）。

2.9 签名密钥轮换

一个容易被忽视的问题：服务端的 Ed25519 签名私钥如果泄露或到期，客户端内嵌的公钥怎么更新？

如果客户端只内嵌一把公钥，私钥一泄露，整个授权体系就崩了——攻击者可以自行签发合法 Token。

解决方案——多代公钥 + kid 字段：

• 客户端编译时内嵌多代公钥（如 key-2024、key-2025、key-2026），每把公钥对应一个唯一的 Key ID（kid）。
• 服务端签发的 Token 在 header 或 payload 中携带 kid 字段，指明应使用哪把公钥验签。
• 正常轮换时，服务端切换到新私钥签发，客户端根据 kid 自动选择对应公钥验签。
• 紧急泄露时，服务端切换到下一代密钥，被泄露的旧密钥签发的 Token 在下次心跳时会被新 Token 替换。

客户端版本更新时追加新一代公钥，确保始终有预埋的下一代密钥可用。这与 JWKS（JSON Web Key Set）的 kid 机制思路相同。

注意：上述"下次心跳时替换旧 Token"只对在线客户端成立。离线授权文件（见 2.8）没有心跳通道，旧密钥签发的离线 Token 在有效期内无法回收。因此离线场景下密钥泄露的代价远高于在线场景，离线授权有效期应设得更短，以缩小泄露后的风险窗口。

三、网络传输安全

3.1 QUIC 的优势

QUIC 基于 UDP，握手与加密合并在一个 RTT 内完成，比 TLS over TCP 更快。

关键配置：必须禁用 0-RTT（Early Data）。TLS 1.3 规范明确指出，0-RTT 在设计上就无法防范网络层重放攻击。授权激活和心跳涉及状态变更，允许 0-RTT 等于允许重放。

3.2 自研协议

如果对安全性要求更高，也可以在 TCP/UDP 之上实现自研二进制协议。优点是协议格式不公开，增加逆向分析成本；缺点是开发和维护成本大，且需要自行处理分包、重传、加密等底层问题。适合对安全性有极端要求且团队有协议开发经验的场景。

3.3 降级策略

政企网络常常封锁 UDP 443，客户端需要实现自动降级：

1

尝试 QUIC 连接（超时 2 秒）→ 失败 → 降级到 HTTPS/1.1

降级后安全性不降低——防重放靠的是 Nonce + Seq 签名，不依赖传输层。

四、授权维度设计

一份完整的授权通常包含三个维度：

过期降级策略

参考 JetBrains 和 TablePlus 的做法，我注意到它们过期后不是完全不能用，而是降级到基础功能集：

• 高级功能禁用（但有明确的错误提示和引导）
• 已有数据可以继续访问（存量保护）
• 定时弹窗提醒续费（不是每次操作都弹，有频率控制）

“降级而非停用”——用户体验更好，续费转化率也更高。对比直接停用，后者容易把用户推向竞品。

试用期

首次安装时启动 7 天全功能试用（不需要输入 key），到期后降级。试用开始时间持久化到本地文件，防止重装应用后重新获得试用。

但仅靠本地文件不够——删除数据目录、重置机器后试用就复活了。更可靠的做法是服务端记录"此硬件指纹已享用过试用"，首次启动时上报指纹查询试用状态。完全离线场景下这个漏洞难以堵上，只能依赖本地持久化 + 在多个隐蔽路径冗余存储试用标记来提高绕过成本。

五、开源工具与参考实现

我在调研过程中发现了几个值得参考的开源项目：

关于 Keygen.sh：它的 API 服务是 Ruby/Rails 栈，且使用的 FCL 协议含商业竞争限制。Go 技术栈的话，参考其架构思路自研核心逻辑比直接引入更灵活。

六、客户端安全加固

6.1 不要用简单的布尔判断

1
2
3
4

// 错误做法：攻击者 patch 一个字节就能绕过
if !isLicensed {
    return ErrUnauthorized
}

这等于"一扇纸门"——逆向工程师改一个跳转指令就过去了。

6.2 业务绞缠（Code Entanglement）

更好的做法是将授权信息与核心业务逻辑深度耦合。例如，将服务端签发的签名作为业务流程初始化的必要参数。攻击者即使 patch 掉校验指令，也无法解算内部关键参数，导致核心功能崩溃。

6.3 二进制完整性校验

攻击者可能直接修改二进制文件（patch 掉校验逻辑）。我了解到几种防御手段：

• 代码签名（Code Signing）：发布时用私钥对二进制签名，启动时自校验。macOS 和 Windows 平台有原生支持（codesign / Authenticode），Linux 下可以自行实现。
• 自校验哈希：编译时将二进制的 SHA256 注入到一个只读段，运行时读自身文件计算哈希并比对。篡改任何字节都会导致校验失败。Go 中的做法是利用 -ldflags -X 在链接阶段写入占位变量，或用构建后脚本计算哈希再通过 debug/buildinfo 或自定义 ELF section 回写。为防止注入值本身被篡改，可以对哈希再做一层 HMAC 签名（密钥编译时内联混淆），或者将校验逻辑分散到多个函数中（与 6.2 业务绞缠结合），让攻击者无法一处 patch 全部绕过。
• 分发渠道签名：配合 GPG 签名或 checksums 文件分发，用户可在安装前验证完整性。

代码签名是最基础的一环。不做这一步，后面所有防御都可以被 patch 绕过。

6.4 防内存注入与调试

攻击者还可能在运行时注入恶意代码或附加调试器来篡改内存中的授权状态。常见的防护手段：

• 反调试检测：Linux 下检查 /proc/self/status 中的 TracerPid 是否非零（有调试器附加）；Go 的 runtime 包也可以检测 GODEBUG 环境变量。

• 关键数据内存保护：Lease Token 和私钥在内存中以加密形式存放，仅在使用瞬间解密，用完立即清零。Go 中有两种方案：

  • runtime/secret（Go 1.26 实验）：标准库，用 secret.Do(func { ... }) 包裹敏感操作，函数返回时立即清零寄存器和栈；堆分配则等 GC 回收时才清零（非即时）。需 GOEXPERIMENT=runtimesecret 编译，目前仅支持 linux/amd64 和 linux/arm64。
  • memguard（第三方库）：手动创建受保护的内存页（mlock 防换出 + mprotect 控制读写权限），提供 LockedBuffer / Enclave 等 API，跨平台，控制更精细但需手动管理生命周期。

  区别：runtime/secret 是语言层面的"用完即焚"，优点是零依赖且栈擦除即时，缺点是堆擦除依赖 GC 时机、平台受限；memguard 是系统调用层面的内存隔离，优点是跨平台且可防 swap 泄漏，缺点是引入第三方依赖且 API 更复杂。高安全场景下两者可以结合使用。

• ptrace 自锁：Linux 下一个进程同一时间只能被一个 tracer 附加。进程启动时对自身执行 PTRACE_TRACEME，后续 gdb/strace 再 attach 就会收到 EPERM。Go 中通过 syscall.RawSyscall 实现：

  1 2 3 4 5 6 7

  // 必须先 runtime.LockOSThread()，确保 syscall 在同一线程执行 runtime.LockOSThread() _, _, errno := syscall.RawSyscall(syscall.SYS_PTRACE, uintptr(syscall.PTRACE_TRACEME), 0, 0) if errno != 0 { // errno != 0 说明已被调试器附加 }

  配合 prctl(PR_SET_DUMPABLE, 0) 还能禁止 core dump，防止内存被离线分析。绕过方式：LD_PRELOAD 注入 stub、patch 检查点、修改 /proc/sys/kernel/yama/ptrace_scope。

• 完整性运行时校验：定时校验关键代码段的哈希，发现被 hook 或修改时退出。Go 中不能直接读取内存中的 .text 段（没有暴露代码段地址的 API），实际做法是读取 /proc/self/exe（Linux）获取磁盘上的二进制文件，用 debug/elf 解析 .text section 后计算哈希，与编译时内嵌的期望值比对。这能检测到二进制被 patch 后再启动的情况，但无法检测运行时通过 mprotect + 内存写入的热 patch——后者需要配合 ptrace 自锁和 W^X（不可写即可执行）策略来缓解。

这些手段都不是万能的——有足够技术和动力的攻击者总能绕过。但它们能显著提高破解成本，让大多数人知难而退。核心思路是"分层防御"：每一层都不完美，但叠加起来足以让破解的投入远超正版的价格。

6.5 编译加固

• 发布版本使用 -ldflags="-s -w" 去除符号表
• 使用 garble 混淆编译，提高逆向成本
• Lease Token 仅驻留内存，不落地明文文件

七、各环境适用性对比

各种部署环境的适用性对比：

Docker 场景的攻击面：挂载宿主 /etc/machine-id 看似指纹稳定，但 /etc/machine-id 本身是普通文本文件，攻击者可以用 -v /path/to/fake-id:/etc/machine-id:ro 挂载任意伪造值。具体风险：

• 起 N 个容器各挂不同伪造 machine-id → 每个容器被视为独立设备，各占一个 Seat。
• 所有容器挂载同一伪造值 → 共享一个 Seat，绕过数量限制。

缓解方式：不能仅依赖单一 machine-id，需结合宿主机的其他不可伪造特征（如 SMBIOS UUID、网卡 MAC）交叉验证；或在容器外部署一个宿主级 Agent 统一管理授权，容器只从 Agent 获取 Token。

八、测试清单

授权系统的每一个安全机制都应该有对应的攻方测试——不是写文档说"应该能防住"，而是构造真实攻击动作验证确实防住了。以下是我整理的 20 项测试清单。

基础功能测试

签名与防重放测试

克隆与分身检测测试

Token 完整性测试

降级行为测试

seq 损坏与时钟快进测试

参考

• Keygen.sh - 授权即服务平台
• keygen-sh/keygen-relay - Go 轻量级自托管授权
• JetBrains License Server 技术文档
• HashiCorp Vault Enterprise Licensing
• Ed25519 - 高速签名算法
• quic-go - Go QUIC 实现
• garble - Go 二进制混淆工具
• denisbrodbeck/machineid - 跨平台机器 ID 库
• DMTF SMBIOS 规范 - 设备指纹技术基础