0%

数字签名和PKI体系

上一章我们介绍了常见的加密算法和实际应用中遇到的问题和解决方案。
同时也遗留了一个问题,如何得知加密传输过程中对方是否可信?如何判别我正在与正确的人进行交互?
换而言之,如何保证A获取的公钥是B发布的公钥,如何保证可追溯性、不可抵赖性?


由于公钥私钥是一对一的,那么有公钥的情况下,想要知道是否是我想交互目标发布的公钥,只要能确定对方私钥和我的公钥是否匹配即可。
那么我们就想到了,只要目标用私钥加密,我用公钥能成功解密就可以验证我所持公钥的有效性了!
这就叫数字签名技术

数字签名

下面简单描述一下数字签名的流程:

  1. 服务端B选择一个原文
  2. 服务端B对原文进行散列,得到原文的散列值并用私钥加密,我们称之为签名值。
  3. 服务端B将原文和签名值公开或者传输给客户端B
  4. 客户端对原文使用同样的散列算法获取到散列值
  5. 客户端使用公钥对签名值解密,如果解密结果与第四步获取的散列值相同,则验证通过

采用数字签名技术,就解决了自己不会被拿到假公钥从而造成数据泄露的问题,而且如果可以验证通过,说明私钥签名是可信的,实现了可追溯性和不可抵赖性。
那么又有人问了,很明显我们平时访问Https网站以及类似的非对称加密场景的时候并没有搞过这些东西啊,
每次都需要验证也太麻烦了吧!没错,事实上这些繁琐的认证都已经被PKI体系代替用户去做了。
那什么又是PKI呢?

PKI体系(公钥基础设施)

PKI又称公钥基础设施,顾名思义公钥基础设施正是为公钥提供一系列管理能力而存在的
那么PKI体系又是如何保证公钥的有效性呢?其核心就是数字证书颁发机构-CA

CA(证书颁发机构)

CA事实上就是上个例子中客户端A和服务端B之间的中介,为公钥出具证书来证明其有效性。具体充当的作用如下(以我博客的https证书为例):

  1. 我作为服务端要先找CA申请数字证书,于是直接在云服务厂商处申请了一家免费的SSL证书。

    事实上申请证书需要生成一个P10请求,也就是按照PKCS#10规范制作的一串请求报文,
    其实就是包含了DN(可识别名)、公钥、散列算法等信息的数据,一般直接获取二进制转成Base64
    或构造成ASN.1结构体(可以理解为Json和Xml的一种结构,特点是属性拥有类型、属性不能乱序) 再转成Base64
    当然云服务厂商会帮我们处理

  2. CA通过线上或线下方式验证信息的真实性,如我的博客,CA应该是通过云服务器厂商来验证我域名的真实性。
  3. CA签发公钥证书,我需要下载证书并放到我的服务器上
    myHttps.png
  4. 我需要在nginx配置支持https请求,并将公钥证书提供出去
  5. 客户端浏览器使用https访问我的博客的时候,可以获取到公钥证书
    https证书
    可以看到证书是采用的2048位的RSA加密算法,并包含了公钥、申请人信息(域名)、签发者信息、有效期、散列算法等原文信息,还有签名值
  6. 浏览器对原文使用散列算法,并使用公钥解密签名,比对解密结果与签名值是否匹配。
  7. 验证通过即显示
    https证书

可见在访问https地址时是浏览器代替用户去做了验证这件事
而在其他场景,比如当我们远程服务器使用SSL证书登陆,则是SSH为我们做了验证这件事

大家应该还记得ssh远程登录的证书是我们执行ssh -keygen生成的,在服务器配置了可信的本机公钥证书才允许了远程登录。
所以证书其实每个人都能做,而在陌生人对陌生人的场景下我们只能相信CA证书。
那么可能有人会问,如果CA是假的怎么办?为什么能相信CA?
答:请无理由相信CA,因为能成为CA机构已经是有国家来背书了,随便举几个我国的CA机构:

  • CFCA(中国金融认证中心) 中国人民银行
  • CTCA(中国电信认证中心) 中国电信
  • 国富安 直属商务部

所以对CA的权威性的疑虑大可不必。


CA虽然是公钥基础设施的核心,但既然叫公钥基础设施这个名字,自然还有许多其他的基础设施,比如:
RA(证书注册机构)、数据传输格式(ASN.1)、数字证书标准(X.509)、PKCS标准等等


现在我们对加密算法、签名算法、PKI体系有了大概的了解,并了解了https请求访问的流程。
那么之后会对我司电子印章业务所涉及到相关知识的地方也做个总结,包括采用的加密算法,数字签名的应用、与加密硬件的交互、电子文档的完整性和追溯性的保证等等
to be continued…