使用WebCrypto API的电子签名

有时我们需要让用户进行电子签名。通常，人们会理解为将您的手写签名以某种方式放在屏幕上。根据管辖范围，可能很好，或者仅存储图像可能还不够。例如，在欧洲，有910/2014号法规，该法规定义了什么是电子签名。从法律文本可以预期到，该定义相当模糊：

“电子签名”是指电子形式的数据，该数据附加到电子形式的其他数据上或与之逻辑关联，并由签字人用来签名；

是的，再读几次，再说几次“ wat”，让我们讨论一下这是什么意思。它基本上可以表示任何东西。仅将绘制的签名的图像（例如使用html画布）附加到数据上并且仍然可以计数，这在技术上是可以接受的。

但是，当我们使用更具体的电子签名类型-高级和合格的电子签名时，情况会好一些：

高级电子签名应满足以下要求：
（a）它与签字人有独特的联系；
（b）有能力识别签字人；（c）使用电子签名创建数据创建的，签名者可以在其唯一的控制下以高度的信心使用该签名；和（d）它以这种方式链接到与其签名的数据，以便可以检测到该数据的任何后续更改。

从技术意义上讲，这看起来像是正确的“数字签名”，例如，使用私钥进行签名，并使用公共密钥来验证签名。 “合格”签名需要由合格的提供者发出，该提供者基本上是一个受信任的证书颁发机构。必须在安全设备（智能卡和HSM）上发布用于放置合格签名的密钥，以便除所有者外，其他任何人都不能访问私钥。

但是，高级签名和合格签名之间的法律区别尚不完全清楚–该法规明确指出，非合格签名也具有法律价值。在浏览器中使用合格的签名（带有智能卡）会给用户带来可怕的体验-在大多数情况下，它会通过Java Applet进行，而Java Applet仅可在Internet Explorer和当今的特殊Firefox版本上运行。替代方案包括处理签名的桌面软件和本地服务JWS应用程序，但是智能卡目前是一个大问题，而且话题不多。

那么，我们如何允许用户“放置”电子签名？我有一个想法，那就是可以完全使用WebCrypto API来完成此工作，如今，WebCrypto API在浏览器中或多或少地得到了支持。这个想法如下：

让用户输入密码以作弊
从密码中获取密钥（例如，使用PBKDF2）
使用派生密钥在用户提交的表单内容上签名
将签名与其余表单数据一起存储
（可选）存储派生密钥以进行验证

这是实现该流程的javascript要点。

许多片段来自非常有用的webcrypto示例存储库。 hex2buf，buf2hex和str2ab函数是实用程序（可惜在js中不是标准的）。

即使有点冗长，代码的作用也很简单。所有操作都使用Promise和“ then”链接在一起，说实话，这对编写和阅读非常繁琐（但我想不可避免）：

密码作为原始密钥加载（转换为数组缓冲区后）
使用PBKDF2导出一个秘密密钥（具有100次迭代）
密钥用于对用户填写的内容进行HMAC“签名”
签名和密钥被存储（在此示例中的UI中）
然后可以使用以下数据验证签名：数据，签名和密钥

您可以在这里进行测试：

存储签名应足以满足“电子签名”的定义。这是只有用户知道的秘密密码，甚至可能意味着这是“高级电子签名”。存储派生的秘密密钥是有问题的–如果存储它，则意味着您可以代表用户“伪造”签名。但是，不存储它意味着您无法验证签名-只有用户可以。根据用例，您可以选择其中一个。

现在，我不得不承认我尝试从密码（RSA和ECDSA）派生非对称密钥对。 WebCrypto API不允许开箱即用。因此，我尝试使用deriveBits（）“生成”密钥，例如，为RSA设置“ n”和“ d”值，为ECDSA设置x，y和d值（可以在稍作搜索后在此处找到）。但是我失败了–您不能仅将任何值指定为importKey参数，并且约束条件未记录在任何地方，除了底层算法细节外，这超出了我的实验范围。

目的是，如果我们仅从密码中获取私钥，就可以轻松地从私钥中获取公钥（反之则不然）–然后我们存储公钥以进行验证，而私钥仍然是真正的私钥，这样我们就不能伪造签名。

我必须在此处添加免责声明，因为我意识到这不是很安全。首先，在许多情况下从密码派生密钥是有问题的。但是，在这种情况下（放置签名），可以。

附带说明–使用WebCrypto API十分繁琐。也许是因为还没有人真正使用过它，所以搜索错误基本上为您提供了Chromium的源代码，而没有其他任何东西。感觉就像是一个未知的领域（尽管文档和示例足以使您入门）。

我不知道以这种方式进行电子签名是否有用。我将其实现为一个实际有意义的用例（参与方成员资格声明签名）。它是否比画布上的手绘签名更好–我认为是这样（除非您从图像中得出密钥，否则，由于较高的熵，手写的密钥会更好）。