当下国家政府推行无纸化，电子签开始频繁出现在各类媒体文章。尤其在腾讯电子签推出小收据之后，越来越多的人关注电子签，详情可参考手写收据太麻烦，下回用微信开！ 。
在此之前，E签宝、法大大等电子签章类产品早已出现，本文就电子签的支撑系统，做一个大概的剖析。抛砖引玉，希望有更多深入的电子签技术文章出现。
一、应用场景模型
在剖析电子签系统之前，我们得清楚电子签的应用场景模型，下面简单说一下个人的理解。
B2B
企业与企业之间的，存在各种合同、协议，不过有一些比较突出的特点：
一般都比较标准化，这种对于电子签的接入是比较友好的，因为签约场景的复用率会比较高，减少企业对接电子签的成本。 一般都比较正式，这就要求电子签约的过程必须有一个严肃的环境，比如接入腾讯会议，布局一个线上签约场景等。
C2C
个人与个人之间的签约场景，相对于B2B来说就非常灵活，特点也很明显：
- 大多没有标准化，这种对于电子签的接入是比较复杂且麻烦的。这一方面更多的可能是从法律效应的角度，将大部分非标准的场景进行标准化，让大家使用通用的模版；同时通用模版也不能太刻板，必须保持灵活性与可扩展性
- 大多情况下都比较随意，或者不太严肃的，比较追求便捷。对于电子签来说，就要尽可能好的体验，满足用户的最短路径完成签约过程。
典型场景如与房东直接签署的租房合同、个人与个人的收据等。
B2C/C2B
B2C/C2B的签约场景，特点正好也是在B2B、C2C之间，既有标准、正式的，也有灵活的，也是大家感知电子签最多的应用场景。典型如劳动合同、竞业协议等
其他
电子签也是可能存在一些除此之外的应用场景，情况就比较多了。一些弱证明的场景，比如一些弱证明的场景，只要完成签署，作为一种形式，不一定需要具有法律依据。或者单方开具证明的场景，电子签系统就弱化为电子签章了。下一节的核心流程，对这种应用场景不一定适用。
小结
总体来说，电子签系统要应对各类应用场景，要具备的一些特性：
- 最重要的：合法性
- 签约场景标准化、灵活性兼备
- 企业对接流程轻量化、个人对接便捷化
- 良好的体验，最短路径
- 良好的扩展性，应对各种签约场景以及突发情况
在结束应用场景的介绍之前，有一个额外需要强调的是，应用产品与应用场景是独立的，并没有绝对的关系。比如小收据，当前的应用场景是C2C，即个人与个人之间的借条/收据，后续也可以扩展到企业与个人、企业与企业之间的收据类业务场景。
二、核心流程
围绕大部分场景，电子签系统的核心流程，包括在签约前需要的企业、个人对接过程，制定签约模板、签约场景，发起签约流程，签署流程。
1. 对接
企业 企业对接，首先面对的问题是企业资质，电子签系统对于企业资质的检查要求是比较高的，这点很容易让人想到办理一些证件时需要准备的大量材料、多个地方跑来跑去。
电子签系统在这一块为了流程轻量化，会考虑使用第三方认证对接，如借助腾讯云的企业对接能力，采用腾讯云助手让企业快捷的进行认证。但是电子签的资质检查与第三方认证不一定完全契合，这种在对接一些渠道时经常会遇到，如企业微信，这就不得不额外提供一些补充信息的录入以及对应的审核过程。
在企业对接中，还有有经办人的概念，这是在企业内参与签约的具体个人，与法人的概念有些类似但并不等于法人，这个在企业内一般需要判断此签约代表人是谁。
个人 个人对接，国内已经是很成熟的场景了，通常都是身份证加人脸识别、手机验证码、银行卡信息检查等。
不过应用场景的不同，会在二要素、三要素、四要素检查之间进行选择，就需要电子签系统在针对不同场景除了考虑便捷之外，还要考虑安全性、合法性。这里不做展开。
2. 定制签约
签约场景 定制签约场景，就是签署方在什么环境下进行签署。
在移动化普及的当代，移动端签署自然是一个很重要的场景。电子签系统目前主要是在微信小程序上进行签署，当然也会有H5签署的布局。而针对比较严肃的场景，可以结合远程会议系统如腾讯会议布局签署环境，如果是现场签署，也可能会嵌入到一些现场设备布局签署环境。
签约模板 签约模板主要是指签署文件的模板，可以理解为具体要签署的文件，这些是要在签署前提交以及准备好的。
发起方的文件形式有各种，如PDF文件、Word文档、Web网页等等，电子签系统通常会以PDF作为标准模板，即将各类文件转化为PDF，然后在PDF上生成控件，用于后续信息的填充以及PDF合成。
控件是指在PDF模板中需要填充信息的区域，简单理解就是纸质文件上要填充信息的地方，比如要填写的企业/个人信息，签署区域等。定位控件目前有以下几种方式：
基于坐标 即基于PDF上的坐标、大小，定义一个控件，通常采用像素px为单位。这种类似于前端在处理输入框，需要定义输入框的坐标值、以及输入框的长宽。
基于文本域 通常是基于PDF表单域，详细定义可参考PDF 表单域属性。这种形式的对接成本比较小，在PDF上做好表单，导入到电子签系统即可。
基于关键字 就是在PDF中，搜索到关键字，在关键字后生成控件，此类关键字必须是签署文件中特有有代表性的文字等。
3. 发起流程
在定制签约场景、签约模板/文件后，就可以发起流程了。发起流程的操作本身比较简单，通过控制台、或者调用API的形式发起一个签约流程，然后通知签约方进行签署，当然结合不通的签约场景，形式各一，这里不做展开
4. 签署流程
最后就是签署流程了，也是电子签过程中最直观的一块。
在签署前或签署时，通常需要对签署人进行认证，如人脸核身等。然后签署方在签署端打开签约文件，进行签署，具体的签署方式可以是手写签名，或者电子签章。
基于手写签名 手写签名即签署时，由签署方在签署端采用手写的签名，这种也是当前用的最多的一种形式。
基于电子印章 电子印章通常在签署前由系统绘制或者由签署方上传的印章图形，能代表签署方。企业方用的居多，往后个人印章会越来越多的使用起来。
到此签署方的操作就完成了，然而电子签系统最终、也是最重要的一个环节就在这之后。即签署完成之后的pdf合成、存证。
在签署方完成签署之后，电子签系统需要将签署内容填入到控件中，即pdf合成，最终形成签署文件，供签署方查看、下载等。而为了保证签署文件的合法性、不可篡改，就需要将签署文件进行存证，保存在具有公信力的地方，比如腾讯至信链。
三、安全保障
上一节我们主要讲的是核心流程，围绕核心流程，是需要很多的安全保障的，这里主要说一下数据安全、证书、存证、私有化。
数据安全
在电子签约的各个场景中，敏感数据是非常多的，从签署企业/人的信息、签署文件的机密性、文件内容的机密性、最终文件的机密性都需要做好安全防护。这里从数据存储、文件存储两方面简单说下。
数据存储 数据存储通常会考虑多维度进行安全保障，比如将数据分敏感级别分别存储、重要敏感信息存储为密文，秘钥尽量不落地等等。这方面可以参考公司数据安全审计的一些要求。
文件存储 文件存储，跟数据存储类似，不过可以统一处理。如将文件加密放在cos上，秘钥采用其他一些安全手段保证安全性。
证书
即CA证书，需要到国家认可的CA机构获取证书，通常会将证书需要的信息给到CA机构，调用CA机构的API生成对应证书。
CA证书通常分为几类
企业长效证书 - 时间较长，如1年 企业实名后，生成私钥，从CA机构获取企业证书，存储在本地，在企业签署时使用
个人长效证书 - 时效较长，如1年 个人实名后，生成私钥，从CA机构获取个人证书，存储在本地，在个人签署时使用
事件型证书 - 时效较短，如1小时 个人进行签署时，生成私钥，从CA机构获取事件型证书，临时存储在本地，在个人签署时使用
在PDF中，可以查看盖章/签名的证书、有效性（通常用Adobe会好一些，其他PDF软件多多少少有些问题）。
这里额外补充一点，国内CA厂商颁发的CA证书，在Adobe中有一些会看到签名存在问题，实际是展示的问题，与证书技术无关。这里涉及到AATL、境外CA等诸多概念，这里就不做展开。详情可以咨询相关法务。
存证
生成的签署文件，为了保证签署文件的合法性、不可篡改等，需要用到第三方公信手段。我们采用的是基于区块链技术的腾讯至信链。
在文件最终形成后，将文件对应的hash、以及一些必要的信息，发送到至信链上。至信链本身也在逐步加大受信范围，如通过微法院等渠道，为取证提供了便捷的渠道。详情可参考至信链官方网站
私有化
提到电子签系统，必不可少的就是私有化。中大型企业，在对接电子签系统，大多会要求私有化部署，将文件、数据控制在企业内部。
私有化部署的方式就有多样化了，不通企业的要求不尽相同。系统设计当然是尽量通用化，如基于私有云的部署体系，或者便捷部署的安装包形式等。这里也不展开，欢迎大家提出方案，一起讨论。
结语
工欲善其事，必先利其器。从电子签系统的设计，到电子签业务的快速展开，大众的普及化，必然需要经过不断打磨的过程。期待更多深度的文章，逐渐形成电子签的生态。也欢迎大家对电子签系统提出各种问题、建议，共同探讨。