基于SM2 的不动产柜面无纸化签署系统设计与实现

蔡昭炜， 刘从军，2， 刘 超

（ 1 江苏科技大学计算机学院， 江苏 镇江 212003； 2 江苏科大汇峰科技有限公司， 江苏 镇江 212003；3 镇江市不动产登记交易中心， 江苏 镇江 212003）

0 引 言

随着电子政务的不断发展及推广，为响应国务院办公厅《关于压缩不动产登记办理时间的通知》（国办发〔2019〕8 号）［1］精神，以及进一步提升省市“放管服”改革、“3550”改革和营商环境优化工作，各地不动产登记交易服务依次展开业务升级。 其中不动产登记交易一窗受理平台［2］的搭建，给不动产业务带来更高的定位、更方便快捷的服务、更全面的服务融合、数据互联共享［3］等多方面提升。 涉及到业务办理中的文书签署也被电子签署所取代［4］，不动产柜面业务办理逐渐向线上或柜面无纸化办理模式转变。

电子签署中所使用的公钥密码算法的密钥对由公钥和私钥组成。 公钥由私钥进行不可逆计算得出，公钥对外公开，私钥需要秘密保存［5］。 协同签名基于门限密码学思想提出，是一种需要多方参与才能完成签名、解密运算的数字签名技术。 将签名密钥分割并存储于不同存储介质中［6］，可以增加攻击、破解密钥的难度同时减少密钥泄露的可能性。2017 年Yehuda Lindell［7］设计了一种快速安全的两方ECDSA 签名方案。 该方案运用Paillier 的同态加密特性，并用零知识证明了方案的安全性，方案具有较好的性能。 2020 年Yudi Zhang 等人［8］提出了一种可证明的、安全实用的两方分布式SM2 签名算法协议，针对发展迅速的物联网移动端场景，能够在不需要重建私钥的情况下生成有效签名。 2020 年冯琦等人［9］设计了一种轻量级的非平衡SM2 协同签名方案，方案中服务器协同客户端完成签名，过程中不暴露密钥信息。

在柜面签署场景下，签名人签署行为的真实性、文书签署行为所产生的签名是否表明签名人的真实意愿，是关注的重点。 随着手工签署文书方式向线上电子签署方式的转变，该问题也随之转变为对签名者身份的核验以及签名所使用密钥的安全保护［10］。 本文考虑上述存在的问题，提出一种用于不动产柜面签署场景的不动产业务办理柜面无纸化签署系统，并基于系统设计一种基于SM2 的协同签名方案，用于生成不动产文书签名。 方案在流程中引入签署人身份认证，使得签名能够表明签名人真实签名意愿，结合PBE 基于口令的密钥算法思想，保护客户端私钥分量，并运用门限密码学思想，将密钥分散在客户端服务器和协同服务器中分别保存，以提高签名密钥安全性。

1 相关知识

1.1 SM2 数字签名算法

SM2 数字签名算法［11］由国家密码管理局发布，是椭圆曲线公钥密码算法（SM）标准。 在SM2 数字签名算法中，通常采用SM3 密码杂凑算法［12］计算摘要。 具体签名步骤如下：

（1）初始化：选定椭圆曲线参数（q，a，b，G，n）并输出；

（2）签名生成：选取私钥d，计算P＝［d］G，将P作为公钥，由此得到密钥对（P，d）；

（3）签名算法：设待签名消息为M，签名者A 生成消息签名需进行如下运算。

①计算杂凑值

其中，IDA是长度为entlen Abit的可辨识标识；ENTLA是entlenA转换而成的两个字节；（xG，yG） 是基点G的坐标；（x，y） 是公钥P的坐标。

②使用随机数发生器产生k，满足k∈［1，n-1］；计算椭圆曲线点（x1，y1）＝［k］G。

③计算r＝（e＋x1）modn。 如果r＝0 或r＋k＝n，则返回上一步。

④利用私钥dA和r计算

⑤输出消息M的签名（r，s）。

（4）验证算法：验证者收到签名者的签名（r，s）和明文M后，利用公钥P进行如下验证：

①计算e′＝，其中＝Z‖M′。

②计算t＝（r′＋s′）modn，其中（r′，s′） 即接收者B 接收到的签名（r，s） 。 如果t＝0，则直接返回验证失败。

③计算（x′，y′）＝［s′］G＋（r′＋s′）P。

④计算R＝（e＋x′）modn

验证R＝r′ 是否成立，如果成立则返回验证成功，反之验证失败。

1.2 PBE 基于口令的密钥

PBE 是一种根据口令生成密钥来加密的方法［13］，在其生成密钥过程中，会通过伪随机数生成器生成一个被称为“盐”的随机数，与口令一起进行密钥计算，该方法可以有效防御字典攻击，其密钥生成过程如图1 所示：

图1 生成PBE 密钥Fig. 1 PBE key generation process

2 系统设计

2.1 系统硬件设计

系统硬件设计如图2 所示。 整体系统可以分为两部分，首先不动产业务办理柜面签署系统的业务模块集成在不动产一窗受理平台中，业务服务器与柜面工作PC 设备相连并置于内网之中，柜面工作人员可以在业务系统中受理业务，推送任务到不动产一窗受理平台的各个子系统中。

不动产业务办理柜面签署系统的签署模块与业务服务器相连，由客户端服务器、身份认证服务器、协同服务器相连构成子系统，同时客户端服务器与不动产业务办理柜面签署设备连接。 客户端服务器与协同服务器是实现数字签名运算的重要组成部分，身份认证服务器提供了对用户身份的核验甄别服务。 本文基于这3 个服务器，设计了一种基于SM2 的协同签名方案，将签名密钥分割，在未来对不动产业务升级远程不见面签署服务［14］时，可以实现服务器的复用。

2.2 系统流程设计

不动产业务办理柜面签署系统的流程设计如图3 所示。 可以根据上述硬件设计的划分模式将整体流程划分为两部分。

图3 系统流程Fig. 3 System process design

第一部分由用户发起业务申请开始。 柜面工作人员在业务系统中根据用户需要办理的业务类型创建签署任务，并登记必要信息，业务系统会提取业务信息创建待签文书模板、生成用户口令Pin。 业务系统最终将签署任务及签署必要数据推送至客户端服务器中，等待用户唤醒。

第二部分由用户发起签署开始。 用户使用柜面签署设备进行身份认证，身份认证成功后唤醒对应签署任务，此时客户端服务器将待签文书展示于柜面签署设备中，并派生客户端私钥分量与协同服务器进行协同密钥运算，计算用户密钥对。 当用户确认待签文书无误并手绘签名提交后，客户端服务器将与协同服务器协同运算，输出对文书的数字签名。客户端服务器验证签名通过后，将输出数据及手绘签名图样合成至待签文书中，得到已签署文书并返回至业务服务器。

3 基于SM2 的协同签名方案设计

为实现不动产业务办理柜面无纸化签署系统中的不动产文书签名服务功能，设计了一种基于SM2的协同签名方案。

3.1 方案流程设计

方案的参与者包括：客户端U（用户）、身份认证服务器IS、协同服务器CS。 其中，身份认证服务器存储了代表IS 身份的公私钥对（PIS，KIS） ，并通过安全信道将公钥PIS发送至客户端U 和协同服务器CS。 方案主要功能包括用户身份验证、协同密钥生成、签名生成。 方案实现步骤如下：

（1）客户端将用户面部识别及id 等数据发送到身份认证服务器（IS）进行身份认证。

（2）IS 向客户端U 和协同服务器（CS）返回认证结果。

（3）客户端U 使用用户口令及身份认证信息派生私钥分量。

（4）客户端U 与CS 协同计算公钥P。

（5）客户端U 与CS 共同等待签署的文书运算数字签名σ。

3.2 用户身份认证

用户身份认证主要由客户端和身份认证服务器协作完成。 具体流程如下：

（1）柜面业务系统根据用户申报信息创建签署任务、生成用户口令Pin， 并推送至柜面签署设备（客户端U）中。 用户使用客户端，通过活体面部识别采集面部信息fu，使用PIS加密面部信息fu、签名任务流水号idtask和用户id，并向身份认证服务器IS发送认证请求Re qver（En cPIS（id，fu，idtask））。

（2）IS 收到认证申请后，使用私钥KIS解密，将获得的用户id 和面部信息fu与公安公民身份信息库进行比对，并生成比对结果fv。

3.3 认证结果通知

IS 根据认证结果向客户端U 和协同服务器CS反馈认证通知，若认证不通过，通知客户端U 和协同服务器CS 终止签署，若认证通过则会进行如下操作：

（1）IS 使用单项散列函数计算H（id‖idtask‖fv）。

（2）以H（id‖idtask‖fv） 为消息，使用私钥KIS对其计算签名Sig nIS（H（id‖idtask‖fv））。

（3）将H（id‖idtask‖fv）、SignIS（H（id‖idtask‖fv）） 发送给客户端U 及协同服务器CS。

客户端和协同服务器使用PIS验证签名SignIS（H（id‖idtask‖fv）），若验证成功继续签署流程，否则终止签署。

3.4 客户端生成私钥分量

客户端U 验证SignIS（H（id‖idtask‖fv）） 成功，即用户身份验证成功后，需要完成签名前的准备工作：选定SM2 椭圆曲线参数生成椭圆曲线； 计算自身的密钥分量。 具体实现过程如下：

（1）选取椭圆曲线E，方程为y2＝x3＋ax＋b，其中a，b∈Fq且满足4a3＋27b2≠0。 选择E上阶为n的基点G＝（xG，yG），n为大于2 160 的素数；选取消息长度为v比特的Hash 函数Hv； 选取输出为256 b 比特串的Hash 函数H256：｛0，1｝ →ZG。

（2）将用户口令Pin视为PBE 算法中的“盐”，与SignIS（H（id‖idtask‖fv）） 共同作为参数输入到密钥派生算法中，生成一个符合SM2 密码算法规则的密钥字符串du。

3.5 协同密钥生成

协同密钥由客户端U 和协同服务器CS 共同生成，实现过程如下：

（1）客户端U 使用密钥字符串dU作为私钥分量，并计算Pu＝［du］G， 将Pu发送给协同服务器CS。

（2）协同服务器CS 接收到Pu后，生成随机数dc，并计算P＝［dc］PU-G，P作为公钥公开。

3.6 协同签名生成

如图4 所示，用户在客户端U 查阅文书并手绘签名后，将与协同服务器CS 进行签名运算，生成数字签名σ。 具体运算步骤如下：

图4 签名运算过程Fig. 4 Signature calculation process

（1）客户端U 计算用户杂凑值：Zu＝H256（ENTLU‖I DU‖a‖b‖xG‖yG‖xp‖yp），置其中M为待签名的文书。 计算e＝Hv。

（2）客户端使用随机数发生器生成随机数k1∈［1，n-1］，计算变量Q1＝［k1］G，将Q1、e发送给协同服务器CS。

（3）CS 使用随机数发生器生成两个随机数k2、k3∈［1，n-1］，计算变量Q2＝k-12Q1和椭圆曲线点（x，y）＝k3G＋k3Q2。

（4）CS 计算r＝（e＋x）modn，使用r计算签名分量和签名分量后，将r、S1、S2发送到客户端U。

（5）客户端U 收到CS 发送的r、S1、S2后，计算签名得到签名σ＝（r，S）。

（6）客户端U 使用公钥P＝［dc］PU-G验证签名σ，如果验证成功则输出签名σ＝（r，S）

3.7 正确性分析

3.7.1 签名生成的正确性

协同密钥由P＝［dc］PU-G生成，则有：

协同服务器CS 计算签名分量为：

根据客户端U 计算签名S可得：

此时，可设签名σ＝（r，S） 是由私钥d＝du dc-1modn和随机数k＝k1k-12k3＋k3modn生成的SM2签名，满足S＝（1-d）-1（k-rd）modn。 因此，方案生成的签名σ＝（r，S） 是正确的。

3.7.2 签名验证的正确性

根据客户端U 计算椭圆曲线点（x，y）：

验证者想要验证签名，需要使用收到的签名σ＝（r′，S′） 和公钥P， 计算椭圆曲线点（x′，y′）＝［S′］G＋（r′＋S′）P，则有：

如果签名σ＝（r，S） 正确，从上式可以得知x＝x′，验证者只需要通过计算R＝（e＋x′）modn和r是否相等来判断签名验证是否成功。

4 实验测试

为验证方案，搭建了硬件环境进行实验测试，硬件参数配置见表1。

表1 硬件参数Tab. 1 Hardware parameters

程序构建基于bcprov-jdk 加密解密库，主要通过业务模拟的方式对系统进行功能测试，同时在测试中对采用的SM2 协同签名方案进行耗时记录，用于性能分析。

4.1 功能测试

根据业务流程设计，签署任务需要在创建阶段采集必要的业务信息，其中包括业务类型、不动产登记信息、办理人身份资料等。 合同文书签署模板需要根据这些必要信息进行创建，并推送至客户端服务器开始签署。

签署任务推送至客户端服务器后，用户使用柜面设备进行业务办理，柜面设备签署界面如图5 所示，用户确认签署并手绘签名后，系统进行签名运算，生成签名后客户端服务器会对所生成签名进行验证。 若验证通过，则合成并输出如图6 所示的已签署文书。

图5 柜面设备签署界面Fig. 5 Counter equipment signing interface

4.2 性能测试

图7 反映了本文SM2 协同签名方案各阶段的性能表现。 在身份认证阶段主要考虑身份认证服务器IS 生成服务器签名SignIS（H（id‖idtask‖fv）） 的耗时，认证通知阶段主要考虑客户端U 和协同服务器CS 对SignIS（H（id‖idtask‖fv）） 的验证耗时。

图7 本文方案各阶段运算耗时Fig. 7 Operation time consumed in each stage

图8 展示在密钥生成阶段、签名生成阶段客户端服务器与协同服务器的耗时情况，同时将两者与原始SM2 数字签名方案的性能表现进行对比。

图8 密钥、签名生成性能对比Fig. 8 Comparison of key and signature generation performance

总体来看，本文方案在密钥生成阶段客户端及协同服务器性能表现接近原始SM2 签名方案，在具有更好性能的服务器架构中，协同服务器的签名运算速度能够进一步得到缩减。

将本文所提签名方案与文献［15］和文献［9］中提出的SM2 协同签名方案进行计算效率对比，结果见表2。 定义Exp 表示一次标量点乘运算或模幂运算，对于形如的多点乘法等同于一次点乘运算所需时间，加法运算所需计算量忽略不计。 文献［9］方案中使用了零知识证明，但在半诚实模型下，通信双方诚实计算可以省略零知识证明，故在对比时只考虑在半诚实模型下的计算效率。

表2 计算效率对比Tab. 2 Calculation efficiency comparison

通过对比分析，本文方案只需要2 轮通信，在密钥生成阶段通信双方都只需要1Exp，总体优于文献［9］和文献［15］中所提方案。 在签名生成阶段中，客户端服务器（参与方A）需要2Exp，优于文献［15］方案，将更多的计算消耗放在硬件性能更好的协同服务器（参与方B）中，转移了部分运算压力。 由此可见，本文方案在计算效率上具有较好表现。

图9 展现了不动产业务办理柜面无纸化签署系统与手工文书签署的在不同业务数量下平均工作效率对比结果。

图9 业务办理效率对比Fig. 9 Comparison of business handling efficiency

在实际调研中发现，不动产柜面业务办理手工文书签署方式在材料、文书的核实、打印、整理、收纳上耗费大量的时间和沟通成本，导致柜面工作效率无法提高。 不动产业务办理柜面无纸化签署系统在实际使用在文书处理、保存上具有显著优势，不但缩短了业务办理时长，提高了柜面工作效率，同时也实现对合同文书的电子化归档和整合，规避了纸质文书归档保存时可能出现管理不善的风险。 因此，本方案在柜面无纸化签署场景下具有良好的应用效果。

5 结束语

针对不动产柜面业务办理手工文书签署向柜面无纸化签署转变而带来的签名人身份认证和密钥安全问题，本文方案提出了一种不动产业务办理柜面无纸化系统，在系统设计中考虑了后续不动产业务升级优化预留了兼容空间，并根据系统设计了一种基于SM2 的协同签名方法，在方案流程融入了身份认证服务，采用门限密码学思想将签名所需要的密钥分割在客户端及协同服务器中，提高了密钥存储的安全性。 此外，方案结合PBE 基于口令密钥算法的思想，提升了客户端私钥分量的安全性，在实际场景中具有良好的应用效果。

由于不动产登记交易业务的特殊性，未来研究方向是将电子公证技术与系统进行融合升级，提升电子文书法律效力，减少办理人业务办理成本。