一、医疗影像存档为何必须走到"硬件级签名"

PACS（Picture Archiving and Communication System，影像存档与通信系统）承载了CT、MR、DR、超声等海量影像及其诊断报告。影像报告是法定病历的组成部分，一旦进入医疗纠纷、保险理赔或司法鉴定场景，报告的真伪、生成时间、签署人身份与内容完整性都会成为举证焦点。对医疗机构而言，影像报告不仅关系到临床诊疗质量，也直接关系到纠纷处置中的责任界定与赔偿认定。

传统做法中，放射科医师在工作站点击"审核通过"即意味着报告定稿，但这一过程往往缺乏强身份认证与防篡改手段：账号密码可被共享、系统时间可被回拨、报告文件可被替换。当纠纷发生、需要证明"这份报告在签署后未被篡改、由特定医师于特定时间签署"时，单纯依赖业务系统日志很难满足证据链闭环。系统日志本身由同一套业务系统生成和保管，存在被运维人员统一修改的可能，其独立证明力在司法场景中常被质疑。

这正是电子签名与硬件加密技术进入医疗影像场景的动因。把签名私钥固化在智能密码钥匙中、由国密算法完成签名验签，可让每一份影像报告在生成瞬间即获得密码学层面的完整性背书与责任绑定，其法律效力不依赖单一业务系统，而依赖公开的密码学标准与可独立验证的签名数据。即便业务系统被攻破、日志被清空，签名包与归档证据仍然独立存在，验证方可以从外部重建验证结论。

在信创认证与国产密码合规日益成为医疗行业硬性要求的背景下，基于国产密码体系（SM1/SM2/SM3/SM4）的硬件签名方案，已成为影像报告合规存档的主流技术路线之一。密码法明确要求关键信息系统使用商用密码保护，等保2.0也将身份鉴别与数据完整性列为测评要点，影像报告作为高敏感病历数据，天然落在强合规区间内。

二、国密UKey的硬件技术底座

所谓国密UKey，本质是内置国密安全芯片的USB接口智能密码钥匙。它并非单纯的存储设备，而是一颗能够独立完成密钥运算的密码协处理器。以安当UKey为例，其内部采用32位RISC架构安全芯片，片上存储约128KB，可原生支持SM1/SM2/SM3/SM4对称与非对称算法，同时兼容RSA、AES、ECC、SHA等国际算法，满足混合环境下的平滑过渡。这种"一芯多算法"的能力，使同一支设备既能服务于存量国际算法系统，也能对接新建国密合规系统。

该设备面向五类典型场景提供能力支撑：Web双因素认证、C/S架构下的身份认证、软件授权保护、会话加密、以及操作系统级双因素登录。在认证方案层面，它支持由弱到强的四档路径：基于KeyID的简易识别、UserName+KeyID的组合校验、真正的签名验签挑战应答、以及对接CA证书体系的强身份认证。对医疗签章而言，应当直接采用最强档——基于CA证书的签名验签，因为只有这一档才能把签名行为与法律意义上的责任人唯一绑定。

对医疗签章场景最关键的是：私钥在芯片内生成且不可导出。这意味着即便UKey丢失、主机被攻破，攻击者也只能物理持有设备，而无法直接提取私钥去伪造签名。配合硬件加密的会话通道，签名请求在主机与芯片之间以密文交互，进一步压缩了中间人攻击面。即便主机被植入键盘记录或内存嗅探程序，攻击者最多窃取PIN的输入过程，却拿不到可用于离线伪造的私钥材料。

对于需要自主集成的信息化厂商，国密UKey提供RESTful API（接口规模约2300项）与C语言动态库两类调用方式，可嵌入PACS报告工作站、影像浏览器或院内集成平台；同时适配信创软硬件环境，满足国产化替代的合规落地。RESTful形态便于云端与远程接入场景下的集中调度，C动态库则适合对时延敏感的本地工作站直连，两种形态可以并存于同一院内的不同子系统。

技术拆解：在影像报告签名中，SM2私钥在UKey芯片内生成，签名运算（SM2-Sign）与摘要运算（SM3）均在设备内完成。主机侧只负责组装待签原文、提交运算指令并取回签名值，私钥永不以明文出现在内存或磁盘。这种"私钥不出硬件"的设计，是把法律意义上的"签字行为"与物理持有的"签名工具"绑定的密码学前提。它同时回答了司法举证中最常被追问的问题：签名是否可能被他人代为完成？只要私钥不可导出且PIN仅本人掌握，代签的技术可行性就被从根本上排除。

三、影像报告SM2签名流程

一份影像报告的合规签名，需要把"谁能签、签了什么、何时签的、签完能不能长期验"四个问题一次性解决。下面给出标准流程，并区分初签与终签两个业务环节。

3.1 待签原文的规范化

签名对象不是整份PDF文件本身，而是经过规范化（canonicalization）的报告摘要原文。一般包括：

• 患者唯一标识（脱敏后的检查号/就诊号）
• 检查类型、设备、部位
• 报告正文文本（所见、印象、诊断意见）
• 关键结构化字段（BI-RADS、医师工号等）
• 报告状态（初审/终审）

将这些字段按约定顺序序列化为JSON，再做SM3摘要，得到待签哈希。规范化的核心在于"顺序与编码唯一确定"：多年后验证方必须以完全相同的字段顺序、相同的字符编码重建摘要，任何字段增删或顺序错位都会使摘要不一致、验签失败。因此序列化规则必须写入签名包元数据，并随档案一同留存，而不能依赖验证时的约定俗成。

3.2 签名与签章

在放射科实务中，一份报告通常经历初审医师与终审医师两道签署。初签确认报告内容，终签确认发布。两道签名可分别由两位医师的UKey完成，各自生成独立的SM2签名值，二者共同构成报告的完整责任链。医师将对应国密UKey插入工作站，输入PIN码解锁芯片，PACS客户端调用签名接口，由芯片用SM2私钥对摘要签名，并附上医师证书序列号。最终形成"报告原文 + SM3摘要 + SM2签名值 + 证书信息"的签名包，随报告一并归档。

3.3 可信时间戳

仅有签名无法抵抗"事后补签"质疑。需在签名后向可信时间戳服务请求时间戳令牌（TSA），将签名值的摘要与权威时间绑定，形成时间戳签名。这样即便10年后私钥已作废，仍能证明"该签名在T时刻已经存在"，为长周期验证提供时间锚点。时间戳服务的权威时间来自国家授时体系，其令牌本身也由时间戳机构的私钥签名，因此验证时间戳的合法性不依赖院内系统时钟。

四、签名与验证时序图

下图描述一次完整的"报告签名 + 时间戳 + 归档"以及后续的"长周期验签"两个阶段的参与方与时序关系。

时序上，签名与归档发生在报告定稿的同一事务内；长周期验证则是独立的、可在任意时点触发的离线校验流程，二者解耦，保证验证不依赖原业务系统的在线状态。即便PACS系统历经多次版本更迭甚至重构，只要签名包与时间戳链被完整迁移，验证结论依然可复现。

五、长周期验证：10年后为何仍可验

医疗影像报告的法律保存期往往长达15至30年，而SM2证书通常一年一签、密钥可能轮换。若仅保存"签名值+证书"，多年后证书早已过期，验证方会得出"证书无效"的结论，签名看似失效。这正是长周期验证要解决的核心问题，其本质是"把有效性从签名时刻固化下来"。

5.1 时间戳链（Time-Stamp Chain）

通过分层时间戳构建信任链：原始签名T0盖上时间戳TS0；一段时间后续签时间戳TS1，其摘要覆盖"TS0+原签名"；如此递推形成TS0→TS1→…→TSn的链。只要链中任一环在其当时证书有效期内被验证，即可向前递推证明原始签名在最早时刻真实存在。时间戳链的设计思想类似"今日为昨日公证、明日为今日公证"，用连续不断的权威时间背书，把有效性一路延续到当下。

5.2 证书状态历史（OCSP/CRL归档）

证书作废状态是随时间变化的。长周期验证不能只查"当前"OCSP，而需归档每次验证时刻的证书状态证据（历史CRL快照或OCSP响应），证明"在签名时刻，该证书处于有效状态"。实务中建议采用定期快照策略：每季度或每半年对参与签名的证书做一次状态固化，并将快照写入归档证据集，避免多年后证书吊销信息无法回溯。

5.3 算法与密钥生命周期管理

硬件加密设备内的密钥具备明确生命周期。以安当UKey为例，芯片内密钥从生成、启用、轮换到停用的全过程均有底层记录，PACS服务端应同步维护一份逻辑侧的密钥档案，记录密钥生成、使用、停用、销毁的时间线。验证方依据密钥档案，可判断签名时刻所用私钥是否处于授权使用期，从而排除"私钥已注销后仍有签名"的异常。密钥档案应作为独立证据保存，且与签名包交叉引用，保证任一时点的签名都能关联到当时有效的密钥状态。

5.4 验证流程伪代码

def verify_long_term(sig_package, ts_chain, cert_status_log):
    # 1. 校验时间戳链完整性
    prev = None
    for ts in ts_chain:
        digest = sm3(sig_package.signature if prev is None else prev.token)
        if not tsa_verify(ts, digest):
            return False, "时间戳链断裂"
        # 校验该时间戳时刻证书有效
        if not cert_was_valid_at(sig_package.cert_sn, ts.time, cert_status_log):
            return False, "签名时刻证书状态异常"
        prev = ts
    # 2. 用存档公钥验签原文
    if not sm2_verify(sig_package.public_key,
                      sig_package.digest,
                      sig_package.signature):
        return False, "签名值不匹配"
    return True, "长周期验证通过"

长周期验证的要点是：把"时间可信"与"签名可信"分别用时间戳链和公钥验证承接，用证书状态历史弥补时间跨度带来的状态变化，使多年后的独立第三方仍可复现验证结论。验证输出的不应只是一句"通过/不通过"，而应包括每一步的证据引用，形成可被司法采信的证据报告。

六、隐私合规：个保法与病历隐私

医疗影像与报告属于敏感个人信息，签名方案本身不能成为隐私泄露的入口。签名解决的是"责任与完整"，但必须在隐私框架内运行，否则会因违规处理敏感个人信息而承担另一维度的法律风险。

6.1 最小化与脱敏

签名原文中应避免直接写入姓名、身份证号等明文个人敏感字段。采用去标识化的检查号作为签名绑定标识，报告可读内容对患者展示时再经授权关联。智能密码钥匙仅对摘要运算，不存储病历原文，降低设备遗失带来的泄露风险。去标识化既满足个保法对敏感个人信息"最小必要"的处理原则，也不削弱签名对报告完整性的背书强度，因为摘要本身已足以证明原文未被篡改。

6.2 知情同意与访问可控

根据《个人信息保护法》，处理敏感个人信息需具有明确目的与严格保护措施。签章系统应记录"谁在何时基于何种授权对哪份报告签名"，形成与签名绑定的操作审计，既满足举证，也满足个保法对处理活动可记录、可追溯的要求。对于远程接入场景下的签名操作，还应记录接入渠道与授权来源，确保每一次签名行为都有据可查、有责可究。

6.3 责任绑定而非身份暴露

电子签名的法律价值在于把"行为"绑定到"责任人"，而不是把"责任人隐私"公开。验证方在举证时只需确认签名来自合法证书与授权私钥，无需读取患者身份明文，从而在合规与举证之间取得平衡。这种"对内可追责、对外不暴露"的取向，是医疗签名区别于普通身份认证的关键特征。

七、合规对照表

下表汇总影像报告签名各环节与对应合规要点的映射关系，便于工程落地自查。表格同时覆盖密码法、电子签名法、等保2.0与个保法的交叉要求。

合规维度	关键要求	UKey签名方案对应点	验证证据
身份真实	签署人确为本人	USBKey双因素（持有+PIN）、CA证书	证书序列号+挑战应答日志
内容完整	报告未被篡改	SM2签名+SM3摘要	验签一致
时间可信	签署时间不可抵赖	可信时间戳链	TSA令牌
长期有效	多年后可验证	时间戳链+证书状态历史	长周期验证报告
隐私保护	个保法合规	去标识化摘要、设备不存原文	脱敏策略配置
密钥安全	私钥不可导出	硬件加密芯片、私钥不出硬件	密钥生命周期档案
国产合规	国密算法/信创	SM1/SM2/SM3/SM4、信创认证	算法标识+适配记录
软件授权	工作站受控	软件授权保护、固件签名	授权令牌+固件校验
密码应用	密码法合规	国密算法全程、密钥内生成	算法与密钥生成记录
等级保护	等保2.0数据完整性	签名验签+会话加密	测评材料与验签日志

八、落地实践：集成与调用示例

8.1 服务端签名请求装配（JSON）

{
  "report_id": "PA-2026-000123",
  "patient_ref": "CHK-9F2A8C",
  "modality": "CT",
  "body_part": "CHEST",
  "findings": "右肺上叶磨玻璃结节，约8mm",
  "impression": "考虑良性可能大，建议随访",
  "signer_code": "RAD-038",
  "status": "FINAL",
  "canonical_order": ["report_id","patient_ref","modality","body_part","findings","impression","signer_code","status"]
}

装配时务必保证canonical_order字段与验签端完全一致，否则会因摘要重建顺序不同而验签失败。该顺序应作为签名包的固定元数据冻结，不得随业务迭代变更。

8.2 工作站调用UKey签名（Bash 伪指令）

# 1. 计算规范化摘要
sm3_digest=$(pacs-sign canonicalize --input report.json)

# 2. 调用智能密码钥匙完成SM2签名（PIN由医师当面输入）
sm2_sig=$(ukey-cli sign \
  --algo sm2 \
  --slot 0 \
  --pin env:UKEY_PIN \
  --digest "$sm3_digest")

# 3. 请求可信时间戳
tsa_token=$(tsa-client request --digest "$sm3_digest")

# 4. 回传PACS服务端归档
pacs-sign submit \
  --report report.json \
  --signature "$sm2_sig" \
  --timestamp "$tsa_token"

PIN应通过安全输入通道获取，避免落盘或出现在进程参数中被其他用户读取。生产环境建议由UKey客户端本地弹窗采集，而非通过命令行明文传递。

8.3 归档与长周期校验（Python）

import json, hashlib

def canonical_sm3(report: dict, order: list) -> bytes:
    raw = "".join(str(report[k]) for k in order).encode("utf-8")
    return hashlib.sm3(raw).digest()  # 示意：实际由UKey芯片内完成

def build_sig_package(report, signature, tsa, cert_sn):
    return {
        "report_id": report["report_id"],
        "digest_order": report["canonical_order"],
        "sm2_signature": signature,
        "tsa_token": tsa,
        "cert_sn": cert_sn,
    }

# 归档时落库签名包，并周期性追加时间戳链、快照证书状态
sig_pkg = build_sig_package(report, sm2_sig, tsa_token, cert_sn)
archive_store.put(report["report_id"], json.dumps(sig_pkg))

归档环节应把签名包、时间戳令牌、证书快照写入同一份不可变证据集，并做多副本与异地留存，防止单点损毁导致举证材料灭失。周期性追加时间戳链的策略，应写入运维手册并自动执行。

8.4 固件与软件完整性

在信创环境下，工作站客户端的发布需做固件签名与软件授权保护，防止被篡改的客户端绕过PIN或伪造调用。每次启动时校验固件签名，确保运行的是经授权的可信代码，这与UKey本身的硬件加密形成端到端的可信闭环。软件授权保护还能限制客户端仅在授权设备上运行，降低UKey被挪作他用的风险。

九、审计与举证闭环

合规签名的终点不是"签上去"，而是"随时能证明"。建议建立三类档案：

1. 签名档案：报告原文、摘要、SM2签名值、证书信息、时间戳令牌。
2. 状态档案：历次证书状态快照、密钥生命周期记录、时间戳链。
3. 操作档案：谁、在何设备、于何时发起签名，PIN校验与双因素记录。

当争议发生，验证方只需调取上述档案，运行长周期验证流程，即可输出一份不含主观判断、完全依赖密码学证据的结论报告，满足司法与监管对电子签名证据的要求。三类档案应相互引用、互可校验：签名档案指向状态档案中的证书快照，操作档案指向具体签名事件，最终汇聚为一条不可割裂的证据链。

在远程接入场景下，操作档案还应记录接入IP段、终端标识与授权来源，使"异地签名"同样具备可追溯性。审计数据本身亦应防篡改，建议采用只增不改的存储策略，并对审计日志再做一次签名固化，防止运维侧统一抹除。

方案参考

面向医疗影像存档的合规签名落地，建议遵循以下通用方法论，而非绑定某一具体产品：

• 以硬件为信任根：将签名私钥限定在具备国密安全芯片的硬件中生成与使用，杜绝私钥以明文形态出现在主机内存或磁盘，从密码学层面确立"持有设备即持有签字能力"。
• 规范化先行：在签名前对待签原文做明确的序列化与摘要规范，保证多年后验证方能以完全一致的规则重建摘要，避免"原文不一致"导致验签失败。
• 时间可信独立化：把时间可信性交给权威时间戳服务，并以时间戳链承接长周期，使验证不依赖签名证书的长期有效。
• 状态可回溯：对证书状态、密钥生命周期做持续快照与归档，使长跨度验证具备"当时当下"的状态证据。
• 隐私最小化：签名绑定去标识化引用，设备与系统均不滞留患者明文敏感信息，满足敏感个人信息处理的可记录、可追溯要求。
• 审计闭环：区分签名档案、状态档案、操作档案三类留存，使举证可独立复现。
• 环境可信：客户端启用固件签名与软件授权保护，端到端维持运行代码的完整性，配合信创认证形成完整可信链。

上述方法适用于各类影像报告、电子病历与医疗文书的合规签名场景，可结合既有PACS与集成平台的能力分阶段实施。