时间: 2021-08-03 09:16:24 人气: 9 评论: 0
最近一直在思考交易鉴权以及对于交易有效性举证的问题，记下来对此的一些知识点与思考，希望能抛**引玉。其中涉及到《电子签名法》的部分内容，虽然我的大学专业中也带了一个“法”字，但是毕竟是“法语”不是“法律”。也和几位做法务领域的朋友交流过，但是《电子签名法》相对小众且新潮，欢迎各位有《电子签名法》实操经验的法务大神吐槽。
其实这一段纯碎是为了凑字数，我想任何一个做 PM 的同学都**说上绝大多目前市面上广泛使用的交易鉴权方式。
账号+密码是目前最普遍的验证方式，还有的业务**增加交易密码二次验证。方案很成熟，也很基础。借用在讨论交易安全时，我们的一个资深开发小哥哥的一句话来证明：（在我们说了问题之后，小哥哥默默的来了一句）我对我的编程生涯第一次产生了怀疑，难道我连登陆系统都写不了了么？账号+密码的方案用户接受程度最高，可以作为登陆等非关键操作的验证方式。
对于这一块，我曾经在《互金产品基础知识（三）作为 P2P 产品经理，你要知道的融资端风控问题》[1]写到一些。
作为上一种鉴权方式的加强版，通过使用密码控件来在保证密码输入框安全，保证密码不被窃取：软键**防止键**监听、星号显示防止被偷看；加密传输防止网络窃取。目前主要的厂商有科篮、飞天等。
但是安全控件兼容性差，必须用 windows+IE 浏览器，且无法应对键**记录器等木马（当然，有一些安全控件还有软键**功能），随着目前账号风控体系的完善，已经很少有系统在使用了。先不考虑。
主要利用指纹、人脸、虹膜等不可变的生物特征进行识别。目前比较广泛的是指纹和人脸识别。
随着各种生物识别设备的普及被窃概率不断增加，且生物特征不可变更，识别准确率不高。之前有过通过三张照**，小视频之类的突破银行存管开户的案例。不过作为一个发展中的技术，我相信生物识别的能力**越来越强。
图形验证码并不是一个狭义的交易鉴权方案，它只能算是人机对抗、过滤机器人（虚假用户）的一个方案。
图形验证码存在着一个天然的悖论：太简单**被机器破解起不到过滤作用，太复杂则**给真实用户带来影响；另外随着现在机器学习图**识别技术的发展，图形验证码（包括其变种模式）已经越来越难起到作用。还有就是现在的打码平台，本质就是个人在输入验证码，单纯依靠图形验证码（不考虑其他辅助措施，比如ip风控、机器指纹识别等）怎么来过滤。
手机验证码是目前比较广泛的鉴权方案，但是手机病毒、伪基站、盗换/复制 SIM 卡等办法都可以进行攻击。当然随着 GSM 网络的退网，伪基站和复制 SIM 卡的方法可能**绝技，但是手机病毒多半估计无法彻底灭绝。
人民银行办公厅曾经在2016年专门下发过《金融业信息安全风险提示》，提示手机验证码短信被黑客拦截的手段、风险和后果。
就是将军令那种东西， HOTP 事件同步或 TOTP 事件同步，一次性口令生成。我曾经写过《给产品经理讲技术-Google验证的原理及应用场景》[2]，有兴趣的可以去看看。
但是问题也很明显：需要多携带一个设备（口令工具）或多安装一个 app，另外目前众多算法已经被公开，安全性较差。
就是一张卡**，每张动态口令卡覆盖有若干个不同的密码。在启用动态口令卡后，进行交易时，需按顺序输入动态口令卡上的密码。
这东西绝对是逆历史潮流的，每张口令卡覆盖的密码有限，每个密码只可以使用一次。用尽后需要重新更换，局限性大。除非你家公司可以在全国任何一个县乡都有点（比如国有大银行爸爸们），否则你还是不要想了。另外密码都在口令卡上以明文方式存在，容易泄漏。
数字证书是用于公开秘钥基础建设（PKI 体系）的电子文件，用来证明公开密钥拥有者的身份。此文件包含了公钥信息、拥有者身份信息（主体）、以及数字证书认证机构（发行者）对这份文件的数字签名，以保证这个文件的整体内容正确无误。拥有者凭着此文件，可向计算机系统或其他用户表明身份，从而对方获得信任并授权访问或使用某些敏感的计算机服务。
计算机系统或其他用户可以透过一定的程序核实证书上的内容，包括证书有否过期、数字签名是否有效，如果你信任签发的机构，就可以信任证书上的密钥，凭公钥加密与拥有者进行可靠的通信。
数字证书的其中一个最主要好处是在认证拥有者身份期间，拥有者的敏感个人数据（如出生日期、身份证号码等）并不**传输至索取数据者的计算机系统上。透过这种数据交换模式，拥有者既可证实自己的身份，亦不用过度披露个人数据，对保障计算机服务访问双方皆有好处。
数字证书必须存储在指定的安全位置中，比如注册表、本地或远程计算机、磁**文件、数据库、目录服务、智能设备或其他位置。
在以上几种鉴权的方式中，认证效力最高、最安全的应该数字证书了。那数字证书是怎么来的呢？和我们文章标题所说的软证书和硬 key 又有什么关系呢？
我从网上找到一张图来说明数字证书的产生：
用户向 RA 申请证书；RA 对用户提交的信息进行核实后向 CA 提出注册请求。CA建立对于该用户的注册，并将注册建立结果返回给RA。
RA将注册结果通知用户，注册结果中包含了两组数字，分别称为“参考号”和“授权码”。（两码）
用户方的软件生成一对公钥和私钥。用户向CA提出证书请求，这个请求信息中还包含了用户的公钥和用户的可甄别名等信息，这些信息在CA创建证书时要用到。
CA创建该用户的数字证书。通过适当方式将证书分发给用户，适当的方式包括：Out-of-band Distribution带外分发、In-band distribution带内分发等多种概念，就不展开了，有兴趣的可以私聊。
——（来源：《CFCA 数字证书的存储和U**Key的安全性》[3]）
数字证书是在PKI体系框架下公钥的表现形式。那么数字证书和私钥到底存储在哪里呢？这就引出了我们今天的题目：软证书和硬 key 。
我们所说的软证书和硬 key 其实指的是我们数字证书和私钥存储在哪里的问题。
软证书一般是将文件存放在电脑/移动设备的指定位置里，比如 Windows **将数字证书存储在注册表（HKLM(HKCC)SoftwareMicrosoftSystemCertificates）和用户配置文件（%USERPROFILE%Application DataMicrosoftSystemCertificatesMy）中。而对应的私钥存处在用户配置文件（计算机：%ALLUSERSPROFILE%Application DataMicrosoftCryptoRSA(DSS)Machine Keys；用户：%USERPROFILE%Application DataMicrosoftCryptoRSA(DSS)）中。 大家有兴趣可以去找找。
而硬 key 则是将私钥和数字证书导入到设备中。这个设备内置单**机或智能卡芯**，可以存储用户的密钥或数字证书。
这两种存储方式只要是安全性的差别：
软证书是以文件形式保存的，并且可以标记允许再次导出，极易受到木马等攻击。另外，软证书不强制用户设置证书使用口令，其他人登录同一台电脑就可以直接使用。曾经出现过银行软证书被攻破的案例，大部分银行在 2008 年以后逐步取消了软证书的网上支付功能。
硬证书则是以UKey移动设备为载体，通过 PIN 码保护 key，且密钥一旦导入 U**-KEY 中，及不可被导出。（甚至无法删除，我和 CFCA 的技术支持确认过这件事，除非我使用专用软件格式化掉这个 Ukey。）
在推荐国标 GB/T 25065-2010 《信息安全技术公钥基础设施签名生成应用程序的安全要求》中也提到安全签名生成设备 SSCD（用来存放签名人的电子签名制作数据，验证签名人鉴别数据，使用电子签名制作数据产生电子签名）需要是：
另外，目前第三方电子合同平台大部分采用的是云托管证书的方案，秘钥在云端存储，不需要任何介质，只需要通过口令（比如密码或者短信验证码）就可以随时随地的进行签名。（说实话，考虑到头部公司的技术实力，我觉得这种方案都比软证书安全，毕竟秘钥是存在一个有着相应技术能力维护的服务器上，而不是存在一些完全不懂电脑的普通人的电脑里。）
我们知道基于密码或短信验证码属于弱身份认证手段，攻击门槛低，容易发生秘钥泄露的事件。同时第三方电子合同平台作为托管方**上（不考虑内控、法律和道德）在一定利益的驱使下是有条件冒充用户替客户签名的。
从国密局至今只为一家云托管方案发放了商用密码产品型号证书来看，这个行业还无法满足可靠电子签名的一些条件。（当然我们也应该看到这些第三方电子合同厂商做的努力，通过完善证据链来修补可靠数字签名的瑕疵，不加这句话我是不是**被电子合同厂商的朋友们骂死……）
另外，国密算法证书标注启用后，国家密码局强制要求不再提供软证书哦。（现在很多金融领域已经被监管要求将加密方式转向国密标准，主要是为了自主可控，这可不是为了什么特色，而是真的有必要。详见 NSA 在 RSA 加密算法中安置了后门——RSA BSAFE[4]。）
关于安全性还有个一个例子从侧面来印证：某家 CA 厂商（就是你们知道的最牛B 的那个），在一次交流中说我们给我们发的软证书上了保险，出现意外保XX；给 XX 项目上来保险，出现问题保 XX。
我问说你们的硬件 key 赔多少？小哥回答我说，我们没上保险，因为ukey **上只有可能因为用户的保管原因造成损失……
**上说，数字证书的基本原理是基于非对称密码机制的 PKI 体系，这个体系和算法（RSA）都是公开的技术并不复杂。Adobe Acrobat 可以很方便的为你的 PDF 增加签名。
但是！在我国有一部法律叫做《电子签名法》（其实包括美国、欧盟等国家和地区都有相关的理发），估计做互金的小伙伴前段时间**被电子合同服务商的商务同时**屏一波，对就是最近刚刚修正过的《电子签名法》。
《电子签名法》规定对于从事电子认证服务的机构采取「资质许可」的形式来确保 CA 机构的权威、公正和可信赖（《电子签名法》第十八条）。截止2018年4月22日，在工信部网站上公示的电子认证服务机构一共37家。
数据来源：工信部-数据资料库-电子认证服务机构设立审批[5]
同时，它还对可靠的电子签名做出了规定，其中提到：（二）签署时电子签名制作数据仅由电子签名人控制。（《电子签名法》第十三条）
同时《电子签名法》第二十八条：电子签名人或者电子签名依赖方因依据电子认证服务提供者提供的电子签名认证服务从事民事活动遭受损失，电子认证服务提供者不能证明自己无过错的，承担赔偿责任。也就是说，电子认证服务提供者需要承担的推定过错责任。
在举证过程中，电子认证服务者举证一个 U **大小的 key 介质似乎要比举证数据文件的所有权容易也直观多了。
另外，还有人一直在和我讨论自建 CA 是否有效的问题。比如四大行的 CA 体系（中行除外，他们用的 CFCA 的）。《电子签名法》第十八条明确指出：从事电子认证服务，应当向国务院信息产业主管部门提出申请……予以许可的，颁发电子认证许可证书……
不过很显然，他们并没有工信部的认可。那是不是是不合法的呢？
也不尽然，《电子签名法》第十三条：当事人也可以选择使用符合其约定的可靠条件的电子签名。第十六条：电子签名需要第三方认证的，由依法设立的电子认证服务提供者提供认证服务。
针对这两条，我发现不同人的解释不太一样，我更倾向于：在双方认可前提下且不需要第三方认证的，可以使用自建 CA。更像是一种擦边球行为，因为有人认为自建 CA 只能在自己系统内部，不如小璋 CA 在小璋集团内部作为文件签署使用，而不能向社**第三方提供服务。不过咱也不知道，咱也不敢问。《电子签名法》任重而道远啊。
关于数字签名及电子合同，我还有一篇文章，有兴趣的可以去看看：【小璋的笔记】电子合同是个啥[6]
[1]《互金产品基础知识（三）作为 P2P 产品经理，你要知道的融资端风控问题》：http://www.woshipm.com/pmd/696772.html
[2]《给产品经理讲技术-Google验证的原理及应用场景》：http://t.cn/AiN4vEwy
[3]《CFCA 数字证书的存储和U**Key的安全性》：http://t.cn/AiN4P7rs
[4] RSA BSAFE：http://t.cn/AiN4P7dv
[5] 工信部-数据资料库-电子认证服务机构设立审批：http://t.cn/RnMdgKm
[6]【小璋的笔记】电子合同是个啥：http://www.woshipm.com/pmd/1036833.html
张小璋，公众号：张小璋的碎碎念（ID：SylvainZhang），人人都是产品经理专栏作家。野蛮生长的产品经理，专注于互联网金融领域。
本文原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自 Pexels，基于 CC0 协议
