# 国密动态口令 OTP 的算法级实现：从 HOTP/TOTP 构造到 SM3 国密适配与令牌分发的工程拆解

> **摘要**：国密动态口令（一次性口令）作为多因素认证里成本低、兼容性好的一种因子，其安全性并不来自"口令本身难猜"，而来自背后的算法构造与种子管理。本文从 HOTP/TOTP 的 HMAC 构造、动态截断与时间窗讲起，下探 SM3 国密适配、时间漂移补偿、种子安全分发、令牌/软令牌/短信三类形态对比、重放窗口与离线挑战响应式 OTP 的工程实现。

---

## 一、场景与问题定义

### 1.1 为什么需要动态口令

国密动态口令解决的核心矛盾是：静态密码一旦被钓鱼、被键盘记录、被撞库，攻击者就能在任意时间地点冒用身份；而一次性口令让"每次登录使用的凭证都不相同且短暂有效"，即便被截获也无法二次使用。在金融、能源、医疗、制造等行业的远程接入、堡垒机运维、网络设备管理场景里，动态口令因其零额外硬件（软令牌）或低成本硬件令牌的特性，成为多因素认证中部署量大的一种因子。本文不讨论"动态口令是什么"的科普，而是下探到算法构造、国密适配与分发的工程实现层面。

### 1.2 动态口令必须解决的三个问题

动态口令系统要成立，必须同时解决三个技术问题：

其一，重放防护。口令在信道里被截获后，系统必须能判断"这个口令是否已经用过"，并拒绝复用。其二，共享密钥的保密性。服务端和令牌持有同一份种子（共享密钥），这份种子一旦泄露，整个口令序列就被攻破。其三，时间一致性。基于时间的 TOTP 依赖服务端和令牌的时钟对齐；时钟漂移若不补偿，合法用户会被错误拒绝。

下面从算法构造逐层拆解。

## 二、HOTP/TOTP 的算法构造

### 2.1 HMAC 与动态截断（dynamic truncation）

无论是 HOTP 还是 TOTP，口令生成的核心都是"用共享密钥对一个变动的输入做 HMAC，再从摘要里截取若干位"。以 HOTP（RFC 4226）为例，输入是计数器 C，输出是：

```
      HMAC(K, C) = H( K ⊕ opad || H( K ⊕ ipad || C ) )
      其中 K 为共享密钥（种子），C 为 8 字节计数器
```

得到 160 比特（SHA1）或更长的摘要后，并不能直接取前 6 位十进制数——那样高位字节的随机性分布并不均匀。RFC 采用动态截断（Dynamic Truncation, DT）：

```
      DT(String) = 取 String 最后一字节低 4 比特（offset = String[末字节] & 0xF）
      取从 offset 开始的 4 字节，拼成 31 位的无符号整数
      Sbits = DT(HMAC) & 0x7FFFFFFF
      OTP   = Sbits mod 10^Digit
```

动态截断的关键点是：offset 由摘要本身的低 4 比特决定，使得整段摘要里的不同片段都能被均匀选中，避免了"永远只取前几位"带来的偏置。Digit 通常为 6 或 8；以 6 位为例，OTP = Sbits mod 10^6，范围 000000–999999。

### 2.2 计数器模式 HOTP 与时间模式 TOTP

HOTP 的变动输入是单调递增计数器 C，每成功认证一次，服务端和令牌各自将 C 加 1。它的好处是不依赖时钟，缺点是两端计数器必须严格同步——一旦令牌多按了几次生成了口令却没用掉，计数器就会"超前"，需要重同步机制拉回。

TOTP（RFC 6238）则把输入从计数器换成时间：

```
      T = (CurrentUnixTime - T0) / X
      TOTP = HOTP(K, T)
      其中 T0 通常为 0，X 为时间步长（典型 30 秒）
```

也就是说，TOTP 是"以时间步长为粒度的 HOTP"。在 30 秒的时间窗内，T 不变，生成的口令不变；跨过一个时间步长，口令刷新。这天然规避了计数器失步问题，代价是把"时钟同步"变成了必须解决的工程问题。

```
  时间轴（步长 X=30s）:
  ┌────────┬────────┬────────┬────────┬────────┐
  T=100    T=101    T=102    T=103    T=104
  [口令A]  [口令B]  [口令C]  [口令D]  [口令E]
  └────────┴────────┴────────┴────────┴────────┘
  服务端校验时允许 T-1、T、T+1 等多个窗口，容忍漂移
```

### 2.3 时间步长、窗口与漂移

时间步长 X 决定了口令刷新频率与容错能力：X 太小（如 10 秒），用户还没输入完口令就过期；X 太大（如 60 秒以上），口令暴露窗口变长。30 秒是兼顾体验与安全的常见取值。

校验端不能只认"当前时间窗"的口令，因为用户设备与服务端时钟存在固有偏差。业界通用做法是设置接受窗口（acceptance window），例如允许当前步长前后各 1 个（即 T-1、T、T+1，覆盖约 90 秒）。窗口越大越宽容，但重放风险也越高——攻击者若在窗口内重放，仍有机会命中。窗口取值需要在"误拒率"和"重放风险"之间权衡。

## 三、国密动态口令的种子注入与安全分发

### 3.1 种子（共享密钥）的生成与编码

种子 K 是动态口令安全的根基，必须来自合格的随机数源（真随机数发生器或经认证的伪随机源），长度通常不低于 160 比特，更长（如 256 比特）可进一步提升抗穷举能力。种子在导入令牌前，常以 base32 或十六进制字符串编码，便于通过二维码、激活码等形式传递。需要强调的是，编码只是为了传输便利，种子本身仍是保密的对称密钥，绝不应当出现在日志、截图或明文配置里。

### 3.2 种子安全分发：加密导入、密钥分割、硬件预置

种子从"生成端"到达"令牌端"的链路，是整条信任链最脆弱的环节。业界通用三类做法：

一是加密导入。服务端将种子按 PSKC（RFC 6030）等标准格式封装，配合加密通道或预先协商的传输密钥下发，避免种子以明文穿越网络。二是密钥分割（split knowledge）。将种子拆成多份，由不同管理员分别持有，必须多人联合才能还原，消除单点泄露风险。三是硬件预置。硬件令牌在出厂或初始化时由安全环境写入种子，出厂后种子不可读出，攻击者无法从令牌提取密钥。

```
  种子分发信任链:
   随机数源 ──► 种子 K（保密）
      ├─ 加密通道 + PSKC 封装 ──► 软令牌（手机 App / 小程序）
      ├─ 密钥分割（A 持份 1，B 持份 2，C 持份 3）──► 联合还原
      └─ 安全环境预置 ──► 硬件令牌（不可读出）
```

### 3.3 种子托管与信封加密

服务端侧，种子不能明文落库。业界通用做法是信封加密：种子用数据密钥（DEK）加密后存储，数据密钥再经根密钥（KEK）加密。根密钥驻留在硬件安全模块（HSM）内，不可导出，所有 HMAC 运算也在 HSM 内完成，使得种子在"生成—存储—运算"全周期都不以明文形态出现在应用内存里。这种"密钥与种子分离托管"的架构，是动态口令系统通过商用密码应用安全性评估时的通用技术答案。

## 四、SM3 国密算法适配

### 4.1 用 HMAC-SM3 替换 HMAC-SHA1 的差异

国密体系要求摘要算法使用 SM3。把 TOTP/HOTP 从 HMAC-SHA1 迁移到 HMAC-SM3，结构上只需把杂凑函数替换：

```
      HOTP-SM3(K, C) = DT( HMAC-SM3(K, C) ) mod 10^Digit
      TOTP-SM3(K, T) = HOTP-SM3(K, T)
```

SM3 输出为 256 比特，比 SHA1 的 160 比特更长，动态截断取 4 字节的算法逻辑完全一致，offset 仍由末字节低 4 比特决定。迁移时不改变时间步长、窗口、位数等上层参数，因此服务端和令牌只要都实现 HMAC-SM3，便可在不改动用户交互的前提下完成国密化。

### 4.2 国密动态口令的 SM3 算法适配要点

国密改造落地时，有几个工程要点容易被忽略：其一，HMAC-SM3 的密钥预处理（padding 到 SM3 分块长度 512 比特）与 SHA1 不同，必须按 GM/T 相关规范实现，不能简单套用 SHA1 的代码路径。其二，部分老旧令牌或第三方验证器只支持 SHA1/SHA256 系列，对接前需确认两端算法族一致，否则同一种子会算出不同口令。其三，国密改造常要求全链路可验证——不仅要能生成 SM3 口令，还要保留对旧算法的兼容窗口，支持灰度切换，避免一次性切换导致存量令牌集体失效。

### 4.3 国密算法与标准兼容

SM3 动态口令在算法层面与 OATH 体系完全兼容——OATH 规范本身对底层杂凑算法留有余地，SM3 作为合规替代，不影响 HOTP/TOTP 的计数、时间、截断流程。因此一套服务端可以同时校验 SHA1/SHA256/SM3 等多种算法族，便于在不同合规要求的系统间平滑过渡。需要指出的是，具体的国密算法标识、密钥长度、实现细节应严格参照现行 GM/T 标准与商用密码产品认证要求，不可凭经验自行约定参数。

## 五、令牌形态对比与选型

### 5.1 硬件令牌 / 软令牌 / 短信验证码 三者对比

动态口令有三种常见呈现形态，安全特性差异明显：

```
  形态              种子存放        是否联网      抗钓鱼     部署成本    典型场景
  ──────────────────────────────────────────────────────────────────────
  硬件令牌          令牌安全芯片      不联网        强         低单价/批量   无手机环境、高安全区
  软令牌(App/小程序) 手机本地存储      生成不联网    中         零硬件       移动办公、远程接入
  短信验证码        服务端实时生成    依赖短信网关   弱         按条计费     临时/低频用户
```

硬件令牌的种子固化在安全芯片内，无法被导出，抗提取能力强，且不依赖手机，适合不允许携带手机的高安全区域。软令牌（手机 App 或移动端小程序）把种子存在手机本地安全存储，生成口令过程不产生任何网络通信，成本低、易分发，是部署量大的形态。短信验证码严格说并非基于共享密钥的 HOTP/TOTP——它由服务端实时生成并通过短信下发，种子不在用户侧，因此抗钓鱼能力弱、依赖运营商通道，通常只作为低频或应急手段。

### 5.2 重放防护与并发窗口

无论哪种形态，重放防护靠的是"用过即废"或"窗口单一"。基于计数器的 HOTP 通过"服务端只接受大于已用计数器"的规则防重放；基于时间的 TOTP 则靠接受窗口：服务端在校验时记录上次成功的时间步 T_used，拒绝 T ≤ T_used 的口令，从而阻断同一窗口内的二次提交。并发窗口（服务端允许 T-1、T、T+1）是为容忍时钟漂移而设的容错，但也等同放大了重放窗口——攻击者若在合法用户刚用完口令的瞬间重放，而服务端恰把该步长计入有效窗口，就可能命中。因此窗口不宜过大，且应配合尝试次数限制、限速、异常告警来压缩攻击面。

### 5.3 离线场景：挑战响应式 OTP

在完全离线、无时间同步能力的环境（如隔离内网、工控终端），基于时间的 TOTP 不可用。此时可采用挑战响应式（challenge-response）OTP：服务端下发一段随机数作为挑战（challenge），令牌端用共享密钥对该挑战做 HMAC 运算，把结果（response）回传，服务端用同一密钥校验。挑战每次不同，天然防重放，且不依赖时钟。代价是交互多一步、需要双向通道，适合高安全、低频的授权确认场景，如关键配置变更、大额操作的二次确认。

```
  挑战响应式流程:
    服务端 ──► 挑战 N (随机数) ──► 令牌/客户端
    令牌/客户端 ── HMAC(K, N) ──► 响应 R ──► 服务端
    服务端 ── 本地用 K 复算 HMAC(K, N)，比对 R ──► 通过/拒绝
```

## 六、工程落地与对接

### 6.1 作为认证因子接入统一认证与 RADIUS

动态口令在工程里通常不是孤立系统，而是作为多因素认证的一个因子，接入统一身份认证平台。典型对接方式有两种：一是应用直连接口，业务系统把用户输入的口令连同用户名送往认证服务端校验；二是 RADIUS 协议对接，把动态口令叠加到既有账号密码之上，由 RADIUS 服务端做"密码 + OTP"的双因子判定，从而让 VPN、堡垒机、网络设备（交换机、防火墙、路由器）这类只认 RADIUS 的旧设备在不改造的前提下获得双因素能力。这种"协议适配层"是动态口令能低成本覆盖存量设备的关键。

### 6.2 时间同步与漂移补偿的工程要点

TOTP 对时钟有要求，工程上要处理好三件事：其一，服务端时钟源应指向可靠的 NTP 时间源，必要时做多源冗余，避免单点时间跳变。其二，漂移补偿策略，服务端在校验失败时，可尝试向前后扩展窗口做有限重同步，并记录该用户的稳态漂移量，用于后续收紧窗口。其三，种子生命周期与批量重签：令牌丢失、员工离职、算法升级时，需要支持单令牌撤销、按组织批量吊销、以及种子轮换（重新下发新种子）。批量重签在工程上要兼顾"不停服"——通常采用新旧种子并存、灰度切换的策略，确保过渡期内两类令牌都可用。

### 6.3 种子生命周期管理小结

把前述各点串起来，一套健壮的国密动态口令系统，其生命周期大致是：合格随机数生成种子 → 信封加密托管于 HSM → 经加密通道或密钥分割安全分发至令牌 → 令牌按 HMAC-SM3 与时间窗生成口令 → 服务端滑动窗口校验并防重放 → 异常时重同步或挑战响应兜底 → 令牌失效时吊销并重签。每一环都可被独立审计、可量化、可回滚，才是能落地进生产环境而不是停留在纸面的方案。

## 七、结语

动态口令看似只是"手机上跳动的 6 位数字"，背后却是 HMAC 构造、动态截断、时间窗、种子托管、国密 SM3 适配、挑战响应等多个工程环节的组合。它在"安全性、成本、兼容性"三角里找到了一个务实的平衡点，因此成为多因素认证部署量大的因子之一。对工程团队而言，落地时的注意力不应只放在"口令怎么生成"，更要放在"种子怎么管、时钟怎么对齐、重放怎么防、失效怎么轮换"这些决定系统真正抗攻击能力的细节上。把算法构造吃透、把分发与生命周期做扎实，动态口令才能从"看着安全"变成"确实安全"。

---

*作者：安当加密-焱垚，安全工程师，专注身份认证、数据加密领域。*


国密动态口令 OTP 的算法级实现：从 HOTP/TOTP 构造到 SM3 国密适配与令牌分发的工程拆解

摘要：国密动态口令（一次性口令）作为多因素认证里成本低、兼容性好的一种因子，其安全性并不来自"口令本身难猜"，而来自背后的算法构造与种子管理。本文从 HOTP/TOTP 的 HMAC 构造、动...

国密动态口令 OTP 的算法级实现：从 HOTP/TOTP 构造到 SM3 国密适配与令牌分发的工程拆解

国密动态口令 OTP 的算法级实现：从 HOTP/TOTP 构造到 SM3 国密适配与令牌分发的工程拆解

摘要：国密动态口令（一次性口令）作为多因素认证里成本低、兼容性好的一种因子，其安全性并不来自"口令本身难猜"，而来自背后的算法构造与种子管理。本文从 HOTP/TOTP 的 HMAC 构造、动态截断与时间窗讲起，下探 SM3 国密适配、时间漂移补偿、种子安全分发、令牌/软令牌/短信三类形态对

技术负责人

编程语言

算法

安全

国密动态口令（OTP）基于HOTP/TOTP算法，通过HMAC-SM3适配、动态截断与时间窗机制实现高安全认证。文章深入拆解种子安全分发、SM3国密改造、时间漂移补偿、重放防护及令牌形态选型，提供硬件/软令牌/短信验证码对比，并给出RADIUS接入与离线挑战响应式OTP的工程落地要点。

多因素认证

商用密码

硬件安全

国密算法

信封加密

数据加密

防火墙

路由器

堡垒机

验证码

路由

短信

国密

2026上云采购 | AI焕新·智启新局

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

国密动态口令 OTP 的算法级实现：从 HOTP/TOTP 构造到 SM3 国密适配与令牌分发的工程拆解-腾讯云开发者社区-腾讯云

国密动态口令 OTP 的算法级实现：从 HOTP/TOTP 构造到 SM3 国密适配与令牌分发的工程拆解

国密动态口令 OTP 的算法级实现：从 HOTP/TOTP 构造到 SM3 国密适配与令牌分发的工程拆解

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐