简体中文
EnglishSecCommerce 的 eIDAS 合格签名如何做到无需签名卡?
更新时间
SecCommerce 的“无签名卡合格签名”依靠的是远程签名（Fernsignatur）：私钥不再存放在用户手中的签名卡上，而是保存在受控的签名服务端，用户通过智能手机完成身份验证和签名授权。它适用于需要在 eIDAS 框架下生成合格电子签名（QES）、但不想分发和管理实体签名卡的场景。需要说明的是，网站只说明了这一能力与产品方向，并未公开具体的信任服务提供方、认证路径和价格，实际部署前应向厂商确认这些细节。
核心机制：把签名卡换成“服务端密钥 + 手机授权”
传统合格签名依赖签名卡：私钥在卡片芯片内，签名时插入读卡器并输入 PIN。SecCommerce 的远程签名把这两件事拆开：
- 密钥位置：签名密钥由服务端签名组件持有和管理，不再随用户移动。
- 身份验证：用户用智能手机完成认证，网站将其列为“Zwei-Faktor-Authentifizierung mit dem Handy”“Sicheres Login / Mobile Push”等能力。
- 签名授权：用户确认签名动作后，由服务端完成实际签名运算。
网站页面标题直接写明“eIDAS - Qualifizierte Signatur ohne Signaturkarten”，并把“Fernsignatur ohne Signaturkarte”列为独立条目，说明这是其产品线中的明确能力，而非附属功能。
一个贴切的例子：员工在笔记本上打开待签的 PDF，点击签名后手机收到推送，确认身份并批准本次签名，服务端用托管密钥完成签名，PDF 中嵌入合格签名。全程没有读卡器，也没有卡片交接。
合格签名与高级签名的区别及选择
SecCommerce 同时提供合格（qualifiziert）和高级（fortgeschritten）签名，网站将其归入“Signaturformen”并强调可按应用场景选择。两者的选择条件大致如下：
| 维度 | 合格电子签名（QES） | 高级电子签名（FES） |
|---|---|---|
| 法律效力 | eIDAS 下与手写签名等效 | 识别签署人、防篡改，但不等同手写签名 |
| 身份核验 | 要求更严格的身份验证 | 相对灵活 |
| 典型用途 | 需要法定书面形式替代的场景 | 内部审批、流程留痕、一般业务文件 |
| 部署成本 | 通常更高，依赖合规的信任服务 | 较低，集成更轻 |
选择时先问“这份文件是否必须满足法定书面形式”，是则倾向 QES；若只是证明“谁在何时确认了什么”，FES 往往够用。网站还提供“Vier-Augen-Workflow”“Mehrfachsignaturen im Workflow”等流程能力，多签和会签场景可一并纳入评估。
配套能力与合规要点
无卡签名不是孤立功能，落地时通常还要考虑：
- 长期有效性：网站列出“Langzeitarchivierung mittels Hashbäumen”，用于签名文件长期保存后的验证。
- 批量与服务器端签名：“Massen-/Einzelsignaturen serverseitig prüfen & erstellen”说明可在服务端批量校验和生成签名，适合高频业务。
- 电子印章：组织层面的“Elektronisches Siegel”可与人员签名配合使用。
- 身份与访问管理：IdM、2FA、FIDO 认证等组件可与签名流程共用同一套身份体系。
- 合规边界：eIDAS 对合格签名有明确的信任服务与证书要求。SecCommerce 提供的是软件组件，合格签名所需的证书和信任服务由谁提供、走哪条认证路径，网站未展开，需在采购时书面确认。
验证与常见卡点
部署后可按以下方式验证是否真正走通：
- 用签名工具或 PDF 阅读器检查签名属性，确认显示为合格签名而非仅高级签名。
- 在另一台设备上验证签名有效性，确认证书链和信任列表配置正确。
- 测试手机推送失败、超时、拒绝授权时的回退流程，确认不会产生“看似签了实际未签”的状态。
- 对归档文件做一次长期验证测试，确认哈希树归档与签名验证能对接。
常见卡点集中在三处：手机端身份验证与签名授权的绑定是否牢固；服务端密钥的访问控制与审计是否可核查；以及合格签名所依赖的证书服务是否已按目标国家/行业的要求配置到位。