数字签名 简介
数字签名(Digital Signature,也叫 公钥数字签名)是只有信息发送者才能产生的,别人无法伪造的一段数字串,这段数字串同时也是对信息的发送者发送信息真实性的一个有效证明。数字签名是 非对称加密算法 与 哈希算法 的应用。数字签名一般用于:
数字签名 举例
以 Alice 和 Bob 进行通讯,窃听者 Eve 进行监听为例。
① Alice 想要给 Bob 发送信息,但又不想其他人知道信息里面的内容。于是 Alice 使用 Bob 发布的公钥 Bob_PublicKey 对信息进行加密。Alice 将加密后的信息发送给 Bob,窃听者 Eve 截获了加密后的信息。Bob 使用自己的私钥 Bob_PrivateKey 对接收到的信息进行解密,得到明文。由于 Bob 的私钥 Bob_PrivateKey 从未在网络上进行传递,窃听者 Eve 无法获取到 Bob 的私钥 Bob_PrivateKey,因此,窃听者 Eve 无法对截获的密文进行解密而获取到明文。由始至终,知道 Bob 私钥的,有且只有 Bob 一个人。
② 对于 Alice 来说,使用 Bob 发布的公钥 Bob_PublicKey 对发送给 Bob 的信息进行加密,可以有效地防止信息被监听和窃取。但是对于 Bob 来说,由于 Bob 的公钥 Bob_PublicKey 是公开的,任何人都可以获取到,其中也包括窃听者 Eve。窃听者 Eve 可以使用 Bob 的公钥 Bob_PublicKey 伪装成 Alice 给 Bob 发送信息,而对于 Bob,他根本不能区分,给自己发送消息的,是否是 Alice 本人。
③ Alice 需要一种方法向 Bob 证明,发送消息的就是 Alice 本人,同时还要保证窃听者 Eve 无法伪造该证明。为此,Alice 采用非对称加密算法,生成了一对秘钥 Alice_PublicKey 和 Alice_PrivateKey,并将公钥 Alice_PublicKey 公布出去:Bob 和 窃听者 Eve 都能获取到 Alice 的公钥 Alice_PublicKey 。Alice 对要发送给 Bob 的信息 PlainText 进行 Hash 运算,得到结果 hash0 。紧接着,Alice 使用自己的私钥 Alice_PrivateKey 对 hash0 进行签名得到签名结果 sign,并将签名结果 sign 连同消息正文 PlainText 一并发送给 Bob(由于这里讨论的是数字签名,为了让描述更加清晰易懂,不再嵌入对明文加密的流程)。
④ Bob 获取到消息明文 PlainText 和签名结果 sign 后,进行以下两步验证:
⑤ 对于窃听者 Eve,即使截获了 Alice 发送给 Bob 的明文 PlainText,也无法对其进行修改。因为 Alice 的私钥 Alice_PrivateKey 从未在网络上进行传递,窃听者 Eve 无法获取到 Alice 的私钥 Alice_PrivateKey,因此,窃听者 Eve 即使修改了明文 PlainText 的内容,也无法伪造出修改后的明文 PlainText’ 的签名结果 sign’ 。由始至终,知道 Alice 私钥的,有且只有 Alice 一个人。而且,在实际业务场景中,Alice 发送给 Bob 的明文 PlainText 还会经过对称加密算法的加密,窃听者 Eve 能不能破解对称加密算法得到明文,还是个问题。(由于这里讨论的是数字签名,为了让描述更加清晰易懂,不再嵌入对明文加密的流程。)
数字签名 注意点
数字签名即信息发送者使用自己的私钥对要发送的信息的 Hash 值进行加密的一种技术,以达到证明信息发送者身份和验证信息完整性的目的。
Question:为什么没有用私钥加密、公钥解密的场景?
Answer:因为公钥是公开发布的,如果要用一个公开发布的秘钥来解密,这个场景就不是加解密,而是数字签名。
Question:为什么不直接使用私钥对消息或文件进行加密,而是对其摘要进行加密?
Answer:因为非对称加密算法效率不高,非常耗时。
数字证书 简介
数字证书(Digital Certificate,也叫 公钥数字证书)是一种证明公钥拥有者身份的电子文档。数字证书内容包括:公钥、公钥拥有者的身份识别信息、验证本证书内容的发行实体(即CA)的数字签名。
数字证书有时候也叫身份证书(Identity Certificate)
数字证书 格式
数字证书的格式普遍采用的是 X.509 V3 国际标准,一个标准的 X.509 数字证书包含以下内容:
通过 Openssl 命令行工具可以查看证书格式:
openssl x509 -in Certificate.crt -text -noout
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
52:04:3b:ed:ec:16:86:25:ba:0e:10:01:83:70:42:fd
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=CN, O=TrustAsia Technologies, Inc., OU=Symantec Trust Network, OU=Domain Validated SSL, CN=TrustAsia DV SSL CA - G5
Validity
Not Before: Sep 28 00:00:00 2017 GMT
Not After : Sep 28 23:59:59 2018 GMT
Subject: CN=home.freemanke.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:bf:a8:30:1b:ea:95:b4:6a:b8:ed:b8:2b:f2:b5:
85:9d:a2:0d:1f:14:d4:71:26:d0:f5:66:37:3e:1a:
b1:a8:20:a1:2b:ea:99:79:d9:8e:ba:0e:1b:6b:b5:
d8:c9:46:4b:5e:63:7e:78:dd:d4:75:4c:9c:2f:03:
6f:62:1e:bd:4f:86:8f:c4:6a:aa:f1:20:28:70:c5:
bf:b9:b6:37:15:d7:a5:f3:1c:d5:63:06:d6:aa:64:
b1:ca:0e:ca:2f:f1:79:2a:da:3d:a8:7e:9b:82:a9:
73:9c:b3:3e:cc:df:ac:9d:a4:e6:cb:47:c1:dc:3e:
f6:74:e7:e4:43:30:e4:12:4d:7d:56:05:a5:45:80:
6c:b5:69:ba:4b:0b:37:ac:5c:85:73:17:a8:ba:a1:
1b:32:21:84:59:88:31:53:1a:25:90:a5:77:b2:07:
b4:0e:57:c6:46:38:36:25:7f:16:61:e6:0e:78:11:
7c:6f:c5:39:bd:13:02:5e:9e:e6:7a:ec:c5:b3:80:
b0:43:cf:7f:05:70:33:3b:1b:4d:4d:5d:78:8a:73:
e2:a1:f1:f9:78:97:08:ba:2a:69:8d:ae:19:f8:ab:
fc:11:9d:fa:26:93:f1:e4:6d:7c:70:f8:58:e7:e2:
d4:0f:36:5d:6c:19:e0:07:c7:bd:a5:74:28:c2:1a:
7a:75
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Alternative Name:
DNS:home.freemanke.com
X509v3 Basic Constraints:
CA:FALSE
X509v3 Certificate Policies:
Policy: 2.23.140.1.2.1
CPS: https://d.symcb.com/cps
User Notice:
Explicit Text: https://d.symcb.com/rpa
X509v3 Authority Key Identifier:
keyid:6D:58:C7:7F:1A:E7:E1:3F:2E:A6:8C:97:35:42:BB:F4:D3:38:AC:3F
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
Authority Information Access:
OCSP - URI:http://trustasia2-ocsp.digitalcertvalidation.com
CA Issuers - URI:http://trustasia2-aia.digitalcertvalidation.com/trustasiag5.crt
1.3.6.1.4.1.11129.2.4.2:
...~...\. ....)6.K...c........SWw...=...x&.u.......X......gp
.....^..]......F0D. s.....r.]..]x[...H.
MUD...G...... ).h}......c..}d*..[d..`....?.7).
Signature Algorithm: sha256WithRSAEncryption
b4:b8:9a:25:b5:a2:0f:fc:1e:84:73:b7:8d:da:5c:53:18:57:
c0:54:f8:82:67:d9:23:c9:ae:f9:8b:cb:1c:af:76:e7:08:9c:
19:a2:50:98:31:41:cf:c0:e3:57:f8:92:05:db:d9:e3:d3:23:
83:e3:20:b9:69:73:1c:14:11:2f:b6:ab:97:7a:a7:48:e6:30:
0a:cc:a0:d5:99:c4:2c:79:f7:4a:97:0e:6d:18:c4:e0:39:1a:
fe:a4:c6:0e:ce:bb:49:75:fd:3f:6c:8e:7a:c3:bc:47:1a:2d:
da:a6:d4:1c:2f:fc:25:91:cc:c4:06:e9:ab:19:3b:3b:1f:27:
0a:4b:33:73:64:1e:86:9f:b8:d9:a2:b1:b1:d2:08:93:55:41:
df:2d:1e:e5:7d:3b:83:3f:ac:c5:05:6a:5e:f9:35:d9:aa:7d:
31:2a:df:95:85:65:44:c3:a9:7e:49:b3:da:06:0c:50:5a:52:
80:36:9d:85:dc:43:e9:94:d4:cc:e7:56:d9:7b:c9:14:b5:94:
cd:00:87:09:97:ef:6c:35:fb:34:84:e4:d9:66:bd:3a:29:10:
3b:d6:b4:97:95:b9:64:21:fb:87:d2:1e:72:b4:4c:0e:92:aa:
48:36:98:5f:00:92:60:78:ef:cd:49:8d:70:5e:49:12:d1:dd:
86:e1:9c:be
数字证书 的存储方式 与 扩展名
数字证书的存储方式一般分为以下两种:
注意:这里的所说的 der 方式和 pem 方式,指的是证书二进制数据的存储方式,而不是指证书的 .der 扩展名 和 .pem 扩展名。
证书扩展名现在基本上都在混用,所以通过证书扩展名并不能唯一确认证书的存储方式,只有实际地根据证书文件内容来确定它是 二进制存储 还是 Base64编码存储
常见的数字证书扩展名:
数字证书 举例
接着上面 Alice 和 Bob 进行通讯,窃听者 Eve 进行监听的例子继续讨论:
① Alice 对发送给 Bob 的信息进行数字签名之后,窃听者 Eve 在劫取到 Alice 的信息后就无法更改其中的内容。虽然这样做看起来很安全了,但是这一切都依赖于 Bob 能正确地接收到 Alice 发布的公钥 Alice_PublicKey 。如果 窃听者 Eve 在 Alice 向 Bob 发送公钥 Alice_PublicKey 的途中,拦截了 Alice 的公钥 Alice_PublicKey,并用自己的公钥 Eve_PublicKey 替换了 Alice 的公钥 Alice_PublicKey,然后发送给 Bob,那么窃听者 Eve 就可以伪装成 Alice 与 Bob 进行通讯。
② Alice 为了保证 Bob 能正确地获取到自己的公钥 Alice_PublicKey,通过证书认证中心(Certificate Authority,简称CA)为自己的公钥 Alice_PublicKey 做认证。证书中心用自己的私钥 CA_PrivateKey,对 Alice 提供的公钥 Alice_PublicKey 和 一些相关信息 一起加密,生成 数字证书(Digital Certificate)。为方便称呼,我们将 Alice 经过证书中心认证过的数字证书,命名为 Alice_Certificate 。
③ 此时,Alice 在发送给 Bob 的信息中 ,不但附加上 Alice 对于信息的数字签名 sign,而且附加上了 Alice 证明自己公钥 Alice_PublicKey 真实性的文件 Alice_Certificate 。Bob 在接收到数据包的时候,首先使用 证书中心(CA)的公钥 CA_PublicKey 对证书 Alice_Certificate 进行解密,得到 Alice 经过 CA 认证的公钥 Alice_PublicKey ,然后再通过 Alice_PublicKey 对数字签名进行验证。
④ 对于窃听者 Eve,即使截获了 Alice 发送给 Bob 的数据包(明文 PlainText、数字签名 sign、数字证书 Alice_Certificate),也无法对其进行修改。因为证书中心(CA)的私钥 CA_PrivateKey,是经过层层保护的,窃听者 Eve 根本无法获取到。没有证书中心(CA)的私钥 CA_PrivateKey,窃听者 Eve 也就无法伪造证明 Alice 公钥真实性的证书 Alice_Certificate,进一步地,也就无法伪造 Alice 的公钥 Alice_PublicKey,也就无法伪装成 Alice 与 Bob 进行通讯。
数字证书 注意点
① 证书中心(CA)对用户提交的公钥和身份信息进行认证的过程,实际上也是在执行数字签名:认证中心把用户证书的基本信息做哈希算法,然后用自己的私钥对哈希值进行加密
因此,前面所说的使用证书颁发机构(CA)的公钥对证书进行解密,实际上执行的是验证 证书颁发机构(CA)的数字签名 的流程:
② 关于根证书:
根证书是证书认证中心(CA)给自己颁发的证书(CA 的自签证书),是信任链的起始点。安装根证书意味着对这个证书认证中心(CA)的信任。证书颁发机构(CA)通过 webtrust 认证后,可将自己的根证书加入公用根证书库。
Question:如何验证根证书可靠性?
Answer:无法验证。根证书是自验证证书,证书颁发机构 CA 是获得社会绝对认可和有绝对权威的第三方机构,这一点保证了根证书的绝对可靠。如果根证书都有问题那么整个加密体系毫无意义。
CRL 与 OCSP
通过前面的介绍我们知道:对于数字证书而言,我们所要做的就是保护好与之匹配的私钥。如果数字证书的私钥遭到泄漏,那么数字证书的安全性将不复存在。在实际使用数字证书的过程中,如果数字证书遗失或者私钥泄漏,则需要通过证书颁发机构(CA)注销证书。
CLR(Certificate Revocation List):证书吊销列表,是公开密钥基础设施(PKI,Public Key Infrastructure)系统中的一个结构化数据文件,该文件包含了证书颁发机构(CA)已经吊销的数字证书的序列号及其吊销日期。 CRL 文件中还包含证书颁发机构(CA)的信息、吊销列表失效时间和下一次更新时间,以及采用的签名算法等。证书吊销列表最短的有效期为 1 个小时,一般为 1 天,甚至 1 个月不等,由各个证书颁发机构(CA)在设置其证书颁发系统时配置。
CDP(CRL Distribution Point):证书吊销列表分发点,是含在数字证书中的一个可以供各种应用软件自动下载最新的 CRL 的位置信息。一个 CDP 通常会列出多个不同的访问方法,以确保如 Web 浏览器和 Web 服务器程序始终可以获取到最新的 CRL 。 CDP 一般是一个可以访问的 HTTP 网址。
OCSP(Online Certificate Status Protocol):证书状态在线查询协议, 是 IETF 颁布的用于实时查询数字证书在某一时间是否有效的标准。上面已经提到,一般证书颁发机构(CA)都只是每隔一段时间(几天或几个月)才发布新的证书吊销列表,可以看出: CRL 是不能及时反映数字证书的实际状态的。而 OCSP 就能满足实时在线查询数字证书状态的需求。它为电子商务网站提供了一种实时检验数字证书有效性的途径,比下载和处理 CRL 的传统方式更快捷、更方便和更具独立性。请求者发送查询请求, OCSP 服务器会返回数字证书可能的三个状态:正常、吊销和未知。OCSP 服务由独立的 OCSP 服务器来提供,一般也是一个可以访问的 HTTP 网站。