一、背景与方案选型

在等保三级或密评合规场景下，应用系统的用户身份鉴别不能仅依赖口令，必须引入基于商用密码的强认证机制。常见的落地方式包括硬件 Ukey、软证书、短信 OTP 等，而协同签名方案则是近年来在政务移动应用场景中快速推广的一种新型路径。

渔翁信息的协同签名方案将 SM2 私钥拆分为两部分——一部分存储在用户手机 APP 内，另一部分存储在协同签名服务端——任何一侧单独都无法完成签名操作，必须双方协同计算才能生成完整的 SM2 数字签名。这一机制在不依赖硬件 Ukey 的前提下，实现了与硬件证书等价的安全强度，同时兼顾了移动端的使用便利性。

本文以一套典型的政务系统为例，完整描述首次登录证书下载、二次登录双因子验证、网页扫码登录三个场景的实现过程。

二、整体架构

系统涉及三个核心组成部分：

手机 APP：用户侧客户端，持有协同签名的本地密钥分量，负责二次认证交互和扫码操作。

业务后台：系统的应用服务端，负责用户管理、会话管理、协同签名接口的代理调用和验证结果的业务处理。

渔翁协同签名服务：提供证书签发、密钥管理、二维码生成、签名验证等核心密码能力。

三者之间的关系是：APP 和网页的所有密码操作最终都通过业务后台与协同签名服务交互，业务后台不存储用户私钥，签名验证结果以接口返回为准。

三、用户注册与初始化

在系统上线前，需要完成存量用户和新增用户的注册同步。业务后台通过协同签名服务提供的批量接口将用户信息同步入协签平台，同时为每个用户分配初始协签口令（如 11111111），该口令仅用于首次下载证书时的身份核验，下载完成后必须强制修改。

注销或冻结用户时，同样需要调用协签平台的维护接口，确保两侧用户状态同步，避免已注销用户仍能通过协签完成认证。

四、首次登录：证书下载与激活

首次登录是整个方案中最复杂的环节，分为以下几个阶段。

4.1 身份核验入口

用户安装 APP 后首次打开，系统要求通过手机号 + 短信验证码完成初始身份核验。短信验证通过后，业务后台判断该用户属于"首次登录"或"证书已过期"状态，触发证书下载流程。

4.2 下载协同证书

APP 使用用户手机号和初始口令（11111111）调用协同签名服务的登录接口，通过验证后，协签服务将该用户的证书下发至 APP 本地存储。证书中包含 SM2 公钥和用户标识信息，本地密钥分量由 APP 安全存储区保管。

4.3 设置保护密码

证书下载成功后，APP 强制引导用户设置协签保护密码，支持手势图案或 PIN 码两种方式。该密码是后续每次触发签名操作时的二次验证凭据，不存储在服务端，仅用于在本地解锁私钥分量。

4.4 更新口令并获取首个二维码

设置完保护密码后，APP 通过业务后台调用协签接口完成以下两件事：

1. 将初始口令 11111111 更新为用户自定义的协签登录口令
2. 请求生成首个认证二维码，用于完成本次首次登录的最终验证

业务后台同时向协签服务轮询二维码扫描结果，等待 APP 完成扫码验签。

4.5 扫码验签完成首次登录

二维码推送至 APP 后，APP 调用协签服务的扫码认证接口，将二维码数据连同本次签名一并提交。协签服务完成协同计算和验签后，返回验签成功及用户信息。业务后台确认结果后，向 APP 下发会话令牌，倒计时结束前用户进入工作台。

安全要点： 整个首次登录过程中，短信验证码用于确认手机号归属，协签初始口令用于从服务端拉取证书，手势/PIN 码用于解锁本地私钥分量，三个因子相互独立、缺一不可。

五、二次登录：双因子快速验证

证书有效期内的后续登录流程大幅简化，但安全等级不降低。

用户打开 APP 后，业务后台检测到证书在有效期内，不再触发重新下载流程，而是直接要求用户输入协签保护密码（手势或 PIN 码）作为二次认证。

验证通过后，业务后台向协签服务请求生成新的认证二维码，并开始轮询验证结果。APP 随即调用扫码认证接口完成签名验证，协签服务返回成功结果，用户进入工作台。

整个过程从输入保护密码到进入工作台通常在 3 秒内完成，用户体验接近传统口令登录，但安全性本质上已是 SM2 数字签名级别。

六、网页扫码：跨设备身份绑定

这一场景解决的是用户通过 PC 浏览器访问网页时的认证问题：PC 端没有协同私钥，需要借助手机 APP 完成签名。

6.1 网页侧等待二维码

用户在浏览器打开系统登录页，业务后台收到请求后立即向协签服务申请生成一个带时效的认证二维码，并将二维码图片渲染在登录页。与此同时，后台开始轮询该二维码的扫描状态，每隔一定时间查询一次。

6.2 手机扫码

用户打开手机 APP，切换到扫码功能，扫描浏览器页面上的二维码，获取其中编码的认证数据。

6.3 签名验证

APP 获取二维码数据后，要求用户输入协签保护密码（手势或 PIN 码），解锁本地私钥分量，随后调用协签服务的扫码认证接口，将二维码数据与本次签名一并提交完成验签。

6.4 浏览器跳转

协签服务返回验签成功后，业务后台的轮询任务拿到结果，向浏览器会话下发认证通过的令牌，页面自动跳转至工作台，倒计时截止前操作有效。

关键设计： 二维码中包含本次会话 ID，协签服务通过会话 ID 将手机端的签名验证结果与 PC 端的等待会话精确绑定，确保扫码结果只对应该浏览器会话，无法被第三方劫持或重放。

七、密评视角下的合规要点

从 GB/T 43201 的测评角度来看，这套方案覆盖了三级系统应用和数据层面的多项核心要求：

身份鉴别： 使用 SM2 数字证书完成用户鉴别，且采用"持有物（手机+证书）+ 所知（PIN/手势）"的双因子组合，满足三级系统"不能仅用口令"的强制要求。

不可否认性： 每次登录均产生 SM2 签名记录，签名结果由协签服务保存，可作为操作不可否认的密码证据。

密钥保护： 用户私钥分量分散存储，任何一侧单独无法完成签名，密钥不以完整形态出现在任何单点，满足"密钥不可软件明文存储"的要求。

密码产品合规： 渔翁协同签名平台已通过国家密码管理局产品认证，可直接引用认证证书号应对密评中的产品合规审查。

八、接入注意事项

二维码时效控制： 认证二维码应设置合理的有效期（建议 60~120 秒），过期后需重新请求，避免被截图复用。

轮询频率与超时： 后台轮询协签验证结果的频率建议 1~2 秒一次，设置最长等待时间（如 120 秒），超时后主动使本次二维码失效。

用户状态同步： 注销、冻结、密码重置等操作必须同步调用协签平台接口，否则会出现业务侧已禁用、但协签侧仍可完成认证的漏洞。

证书有效期管理： 建议在证书到期前 30 天向用户推送更新提醒，到期前 7 天强制引导更新，避免证书突然失效导致用户无法登录。

降级策略： 协签服务不可用时是否允许降级为短信验证码登录，需结合业务安全要求和密评要求事先明确，三级系统通常不建议在核心业务中开放降级通道。

九、小结

渔翁协同签名方案在不引入硬件 Ukey 的前提下，实现了基于 SM2 的双因子强认证，在政务移动应用场景中具备较强的落地可行性。其核心价值在于将密钥保护的责任分散到协签服务端和用户手机两侧，单点失陷不足以完成完整签名操作。

对于需要同时覆盖 APP 端和 PC 网页端的系统，扫码登录机制将两种终端的认证能力统一汇聚到手机端的密码操作上，既满足合规要求，也避免了 PC 端需要安装 Ukey 驱动的部署复杂度。

实际接入时建议在测试环境充分模拟首次登录、证书过期、账号注销等边界场景，提前与渔翁技术支持确认各接口的幂等性和异常返回码处理逻辑，是保证上线稳定性的关键一步。