密码学（四）

最新推荐文章于 2021-01-28 12:59:51 发布

Airths

最新推荐文章于 2021-01-28 12:59:51 发布

阅读量3.4k

点赞数

分类专栏： iOS 安全攻防

本文链接：https://blog.csdn.net/Airths/article/details/106997187

版权

iOS 安全攻防专栏收录该内容

78 篇文章 30 订阅

订阅专栏

数字签名

数字签名简介

数字签名（Digital Signature，也叫公钥数字签名）是只有信息发送者才能产生的，别人无法伪造的一段数字串，这段数字串同时也是对信息的发送者发送信息真实性的一个有效证明。数字签名是非对称加密算法与哈希算法的应用。数字签名一般用于：
1. 验证信息发送者的身份
2. 验证发送信息的完整性
数字签名举例

以 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 后，进行以下两步验证：
1. 身份验证：Bob 使用 Alice 的公钥 Alice_PublicKey 对得到的签名结果 sign 进行解密。如果解密失败，则说明 Alice 的签名结果 sign 被篡改，此签名不属于 Alice，更进一步地，消息的发送者很有可能不是 Alice 。如果解密成功，则证明此签名属于 Alice，并获取到经 Alice 签名过的明文 PlainText 的哈希值 hash0 。
2. 信息完整性验证：Bob 对接收到的消息明文 PlainText 使用与 Alice 相同的 Hash 运算，得到结果 hash1 。Bob 对比 hash0 与 hash1，如果值相同，则证明明文 PlainText 是完整的。如果结果不同，则说明明文 PlainText 被人篡改。
⑤ 对于窃听者 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 数字证书包含以下内容：

证书的版本信息
证书的序列号（每个证书都有一个唯一的证书序列号）
证书所使用的签名算法
证书的发行机构名称，命名规则一般采用 X.500 格式
证书的有效期，通用的证书有效期一般采用 UTC 时间格式，它的计时范围为1950-2049
证书所有人的名称 (Subject)，命名规则一般采用 X.500 格式
证书所有者的公钥
证书发行者 (Issuer，即CA) 对证书的签名
证书的扩展信息

通过 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

数字证书的存储方式与扩展名

数字证书的存储方式一般分为以下两种：
1. der 方式，直接存储证书的二进制数据，不可读，不便于传递和交换
2. pem 方式，存储的是证书二进制数据的 Base64 编码，可读取，便于传递和交换
注意：这里的所说的 der 方式和 pem 方式，指的是证书二进制数据的存储方式，而不是指证书的 .der 扩展名和 .pem 扩展名。
证书扩展名现在基本上都在混用，所以通过证书扩展名并不能唯一确认证书的存储方式，只有实际地根据证书文件内容来确定它是二进制存储还是 Base64编码存储

常见的数字证书扩展名：
1. 扩展名为 .key，一般用于存储 Base64 编码格式的私钥
2. 扩展名为 .pem、.cer、.crt，使用 PEM 方式存储，存储的是 DER 方式下的 Base64 编码
  并在编码的头尾加上
  起始行 -----BEGIN CERTIFICATE-----
  结束行 -----END CERTIFICATE-----
3. 扩展名为 .der 、.cer、 .crt，使用 DER 方式存储，存储的是证书的二进制数据
4. 扩展名为 .p12，一般包含了证书和对称加密后的私钥
5. 扩展名为 .pfx，是 .p12 的前身
数字证书举例

接着上面 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）的数字签名的流程：
1. 验证证书颁发机构身份：使用证书颁发机构（CA）的公钥对数字证书里面的 认证机构数字签名 进行解密。如果解密失败，则说明此签名并非属于证书颁发机构（CA），证书无效。如果解密成功，则说明此签名属于证书颁发机构（CA），并获得证书颁发机构（CA）关于本证书信息的 Hash 值，接着进行第二步：验证证书内容的完整性。
2. 验证证书内容的完整性：使用与证书颁发机构（CA）相同的 Hash 算法，对证书里面的信息做 Hash 运算，得到当前证书信息的 Hash 值。对比当前证书信息的 Hash 值与证书颁发机构（CA）关于本证书信息的 Hash 值，如果不一致，则说明证书内容遭到篡改，证书无效；如果一致，则说明证书内容完整有效，可以依照证书里面指定的用法用途，使用证书里面保存的公钥。
② 关于根证书：

根证书是证书认证中心（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 网站。

HTTPS 与数字证书

HTTPS 握手的简要流程如下图所示：
其中，验证数字证书时，常见的三个风险提示为：

此网站出具的安全证书不是由受信任的证书颁发机构颁发的（数字证书可能是自签的）。
此网站出具的安全证书已经过去或还未生效（数字证书不在有效期内）。
此网站出具的安全证书是为其他网站地址颁发的（网站冒用数字证书）。

谷歌浏览器内置的受信任的 CA 的列表

客户端（浏览器）的 “证书管理器”，有 “受信任的根证书颁发机构” 列表
客户端（浏览器）会根据这张列表，查看解开数字证书的公钥是否在列表之内
访问路径为：设置 - 隐私设置和安全性 - 安全 - 管理证书 - 受信任的根证书颁发机构
通过谷歌浏览器查看淘宝网的数字证书

证书常规选选项卡
证书详细信息选项卡
证书路径选项卡

Airths

关注

0
点赞
踩
3

收藏

觉得还不错? 一键收藏
0
评论
密码学（四）

目录数字签名数字证书HTTPS对称加密算法数字签名数字签名简介数字签名（Digital Signature，也叫公钥数字签名）是只有信息的发送者才能产生的，别人无法伪造的一段数字串，这段数字串同时也是对信息的发送者发送信息真实性的一个有效证明。数字签名是非对称加密算法与哈希算法的应用。数字签名一般用于：验证信息发送者的身份验证发送信息的完整性数字签名举例以 Alice 和 Bob 进行通讯，窃听者 Eve 进行监听为例。① Alice 想要给 Bob 发送信息，但又
复制链接

扫一扫