1- 安全机制

1 安全机制

1.1 墨菲定律

墨菲定律：一种心理学效应，是由爱德华·墨菲提出的，原话：如果有俩种或俩种以上的方式去做某件事，而其中一种选择方式导致灾难，则必定有人会做出这种选择

主要内容：

• 任何事情都没有表面看起来那么简单
• 所有的事都会比你预计的时间长
• 会出错的事总会出错
• 如果你担心某种情况发送，那么它就更可能发生

1.2 信息安全防护的目标

• 保密性 Confidentiality
• 完整性 Integrity
• 可用性 Usability
• 可控制性 Controlability
• 不可否认性 Non-repudiation

1.3 安全防护环节

• 物理安全：各种设备/主机、机房环境
• 系统安全：主机或设备的操作系统
• 应用安全：各种网络服务、应用程序
• 网络安全：对网络访问的控制、防火墙规则
• 数据安全：信息的备份与恢复、加密解密
• 管理安全：各种保障性的规范、流程、方法

1.4 常见的安全攻击 STRIDE

• Spoofing 假冒
• Tampering 篡改
• Repudiation 否认
• Information Disclosure 信息泄漏
• Denial of Service 拒绝服务
• Elevation of Privilege 提升权限

1.5 安全设计基本原则

• 使用成熟的安全系统
• 以小人之心度输入数据
• 外部系统是不安全的
• 最小授权
• 减少外部接口
• 缺省使用安全模式
• 安全不是似是而非从 STRIDE 思考
• 在入口处检查
• 从管理上保护好你的系统

1.6 常用安全技术

• 认证
• 授权
• 审计
• 安全通信

1.7 加密算法和协议

• 对称加密
• 非对称（公钥）加密
• 单向加密
• 认证协议

1.7.1 对称加密算法

对称加密：加密和解密使用同一个密钥

特性：

• 加密、解密使用同一个密钥，效率高
• 将原始数据分割成固定大小的块，逐个进行加密

缺陷：

• 密钥过多
• 密钥分发
• 数据来源无法确认

常见对称加密算法:

• DES：Data Encryption Standard，56bits
• 3DES：
• AES：Advanced (128, 192, 256bits)
• Blowfish，Twofish
• IDEA，RC6，CAST5

1.7.2 非对称加密算法

非对称加密：密钥是成对出现

• 公钥：public key，公开给所有人，主要给别人加密使用
• 私钥：secret key，private key 自己留存，必须保证其私密性，用于自已加密签名
• 特点：用公钥加密数据，只能使用与之配对的私钥解密；反之亦然

功能：

• 数据加密：适合加密较小数据,比如: 加密对称密钥
• 数字签名：主要在于让接收方确认发送方身份

缺点：

• 密钥长,算法复杂
• 加密解密效率低下

常见算法：

• RSA：由 RSA 公司发明，是一个支持变长密钥的公共密钥算法，需要加密的文件块的长度也是可变的,可实现加密和数字签名
• DSA（Digital Signature Algorithm）：数字签名算法，是一种标准的 DSS（数字签名标准）
• ECC（Elliptic Curves Cryptography）：椭圆曲线密码编码学，比 RSA 加密算法使用更小的密钥， 提供相当的或更高等级的安全

1.7.2.1 非对称加密实现加密

接收者

• 生成公钥/密钥对：P 和 S 公开公钥 P，保密密钥 S

发送者

• 使用接收者的公钥来加密消息 M 将 P(M)发送给接收者

接收者

• 使用密钥 S 来解密：M=S(P(M))

1.7.2.2 非对称加密实现数字签名

发送者

• 生成公钥/密钥对：P 和 S
• 公开公钥 P，保密密钥 S
• 使用密钥 S 来加密消息 M
• 发送给接收者 S(M)

接收者

• 使用发送者的公钥来解密 M=P(S(M))

1.7.2.3 RSA 和 DSA

RSA：公钥加密算法是 1977 年由 Ron Rivest、Adi Shamirh 和 LenAdleman 在（美国麻省理工学院）开发的，RSA 取名来自开发他们三者的名字，后成立 RSA 数据安全有限公司。RSA 是目前最有影响力的公钥加密算法，它能够抵抗到目前为止已知的所有密码攻击，已被 ISO 推荐为公钥数据加密标准。RSA 算法基于一个十分简单的数论事实：将两个大素数相乘十分容易，但那时想要对其乘积进行因式分解却极 其困难，因此可以将乘积公开作为加密密钥

DSA (Digital Signature Algorithm)：1991 年 7 月 26 日提交，并归属于 David W. Kravitz 前 NSA 员工， DSA 是 Schnorr 和 ElGamal 签名算法的变种，被美国 NIST 作为 SS(DigitalSignature Standard)， DSA 是基于整数有限域离散对数难题的，其安全性与 RSA 相比差不多。DSA 只是一种算法，和 RSA 不同之处在 于它不能用作加密和解密，也不能进行密钥交换，只用于签名,它比 RSA 要快很多

1.7.3 使用 gpg 实现对称和非对称加密

1.7.3.1 实现对称加密

对称加密 file 文件

[19:10:49 root@centos8 ~]#gpg -c passwd.txt

在另一台主机上解密 file 文件，-o 表示解密后生成的文件，-d 要解密的文件

[19:12:09 root@centos7 ~]#gpg -o passwd.txt -d passwd.txt.gpg

注意：加密时需要输入密码，解密时也需要输入密码

1.7.3.2 实现公钥加密

目标：在 hostB 主机上用公钥加密，在 hostA 主机上解密 B-->A

在 hostA 主机上生成公钥/私钥对

[19:16:39 root@centos8 ~]#gpg --gen-key

在 hostA 主机上查看公钥

[19:17:46 root@centos8 ~]#gpg --list-keys

在 hostA 主机上导出公钥到 zhang.pubkey

[19:17:52 root@centos8 ~]#gpg -a --export -o zhang.pubkey

从 hostA 上复制公钥文件到需加密的 B 主机上

[19:19:12 root@centos8 ~]#scp zhang.pubkey 192.168.10.71:

在需加密数据的 hostB 主机上生成公钥/私钥对

[19:21:06 root@centos7 ~]#gpg --gen-key

在 hostB 主机上导入公钥

[19:25:13 root@centos7 ~]#gpg --import zhang.pubkey
[19:25:58 root@centos7 ~]#gpg --list-keys

用从 A 主机导入的公钥，加密 hostB 主机的文件 file，生成加密文件

[19:28:11 root@centos7 ~]#gpg -e -r zhang fstab

复制加密文件到 hostA 主机

[19:28:44 root@centos7 ~]#scp fstab.gpg 192.168.10.81:

在 hostA 主机解密文件

[19:20:06 root@centos8 ~]#gpg -o fstab -d fstab.gpg

删除公钥和私钥

[19:30:59 root@centos8 ~]#gpg --delete-secret-keys zhang
[19:28:58 root@centos7 ~]#gpg --delete-keys zhang

1.7.4 单向哈希算法

哈希算法：也称为散列算法，将任意数据缩小成固定大小的“指纹”，称为 digest，即摘要

特性：

• 任意长度输入，固定长度输出
• 若修改数据，指纹也会改变，且有雪崩效应，数据的一点微小改变，生成的指纹值变化非常大。
• 无法从指纹中重新生成数据，即不要逆，具有单向性

功能：数据完整性

常见算法

md5: 128bits、sha1: 160bits、sha224 、sha256、sha384、sha512

常用工具

• md5sum | sha1sum [ --check ] file
• openssl、gpg
• rpm -V

数字签名

RPM 文件完整性

rpm --verify package_name (or -V)

rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat*

rpm --checksig pakage_file_name (or -K)

1.7.5 综合应用多种加密算法

1.7.5.1 实现数据加密

实现数据加密，无法验证数据完整性和来源

发送方：先使用对称加密加密源数据生成对称密钥，然后用非对称加密加密之前生成的对称密钥生成加密的对称密钥然后发送
接收方：使用自己的非对称密钥的私钥来解密加密的对称密钥，之后得到对称加密的数据然后使用对称密钥来解密得到数据

1.7.5.2 实现数字签名

不加密数据，可以保证数据来源的可靠性、数据的完整性和一致性

发送方：使用 hash 算法提取数据的摘要，然后使用非对称加密的私钥加密摘要得到数字签名然后发送
接收方：使用非对称加密的公钥解密数字签名得到摘要，然后对数据进行 hash 算法得到元数据摘要，用元数据摘要和之前解密的摘要进行比对

1.7.5.3 综合加密和签名

即实现数据加密，又可以保证数据来源的可靠性、数据的完整性和一致性

发送方：对数据进行 hash 算法得到数字摘要，然后使用自己的非对称加密的私钥加密数字摘要得到数字签名，然后把数字签名和数据使用对方的公钥来加密得到加密的密文发送
接收方：先使用自己的私钥解密密文得到数字签名和数据，对数字签名使用使用对方的公钥进行解密得到数字摘要同时对源数据进行 hash 算法也得到数字签名，最后把俩个数字签名进行比对
方法 2：对称 key{Sa[hash(data)]+data}+Pb(对称 key)

发送方：对数据进行 hash 算法得到摘要，使用自己的私钥对摘要进行加密得到数字签名，对数字签名和数据进行对称加密得到对称密钥，使用对方的公钥对对称加密进行加密得到加密的对称密钥然后发送
接收方：使用自己的私钥对加密的对称密钥解密得到对称密钥，使用对称密钥对对称密钥进行解密得到数据和签名，使用对方的公钥对数字签名解密得到摘要信息，对数据进行 hash 算法也得到摘要信息，最后进行比对如果没有错误得到数据

1.7.6 密码交换

密钥交换：IKE（ Internet Key Exchange ）

• 公钥加密：用目标的公钥加密对称密钥
• DH (Deffie-Hellman)：生成对称（会话）密钥，由惠特菲尔德·迪菲（Bailey Whitfield Diffie）和马丁·赫尔曼（Martin Edward Hellman）在 1976 年发表

参 看 ： https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange

DH 实现过程：

• A: g,p 协商生成公开的整数 g, 大素数 p
• B: g,p
• A:生成隐私数据:a (a<p)，计算得出 g^a%p，发送给 B
• B:生成隐私数据:b,(b<p)，计算得出 g^b%p，发送给 A
• A:计算得出 [(g^b%p)^a] %p = g^ab%p，生成为密钥
• B:计算得出 [(g^a%p)^b] %p = g^ab%p，生成为密钥

范例:

g=23
p=5

A:a=6
23^6%5=4

2^6%5=4

B:b=15
23^15%5=2

4^15%5

[root@centos8 ~]#echo 23^15%5|bc
2
[root@centos8 ~]#echo 23^6%5|bc
4

1.8 CA 和证书

1.8.1 中间人攻击

Man-in-the-middle，简称为 MITM，中间人

1.8.2 CA 和证书

PKI：Public Key Infrastructure 公共密钥加密体系

• 签证机构：CA（Certificate Authority）
• 注册机构：RA
• 证书吊销列表：CRL
• 证书存取库：

X.509：定义了证书的结构以及认证协议标准

• 版本号
• 序列号
• 签名算法
• 颁发者
• 有效期限
• 主体名称

证书类型：

• 证书授权机构的证书
• 服务器证书
• 用户证书

获取证书两种方法：

• 自签名的证书： 自已签发自己的公钥
• 使用证书授权机构：
  • 生成证书请求（csr）
  • 将证书请求 csr 发送给 CA
  • CA 签名颁发证书

1.8.3 安全协议 SSL/TLS

1.8.3.1 TLS 介绍

SSL：Secure Socket Layer，TLS: Transport Layer Security

1994 年，NetScape 公司设计了 SSL 协议（Secure Sockets Layer）的 1.0 版，但是未发布

1995：SSL 2.0 Netscape 开发

1996：SSL 3.0

1999：TLS 1.0

2006：TLS 1.1 IETF(Internet 工程任务组) RFC 4346，从 2020 年 3 月起，停止支持 TLS 1.1 及 TLS 1.0 版本安全协议，谷歌（Chrome）、Mozilla（Firefox）、微软（IE 和 Edge） 、苹果（Safari） 都会发布新版浏览器执行这个策略

2008：TLS 1.2 当前主要使用

2018：TLS 1.3

功能：

• 机密性
• 认证
• 完整性
• 重放保护

1.8.3.2 SSL/TLS 组成

• Handshake 协议：包括协商安全参数和密码套件、服务器身份认证（客户端身份认证可选）、密钥交换
• ChangeCipherSpec 协议：一条消息表明握手协议已经完成
• Alert 协议：对握手协议中一些异常的错误提醒，分为 fatal 和 warning 两个级别，fatal 类型错误会直接中断 SSL 链接，而 warning 级别的错误 SSL 链接仍可继续，只是会给出错误警告
• Record 协议：包括对消息的分段、压缩、消息认证和完整性保护、加密等

1.8.3.3 TLS 实现过程

实现分为握手阶段和应用阶段

• 握手阶段(协商阶段):客户端和服务器端认证对方身份（依赖于 PKI 体系，利用数字证书进行身份认证），并协商通信中使用的安全参数、密码套件以及主密钥。后续通信使用的所有密钥都是通过 MasterSecret 生成
• 应用阶段:在握手阶段完成后进入，在应用阶段通信双方使用握手阶段协商好的密钥进行安全通信

目前密钥交换 + 签名有三种主流选择：

• RSA 密钥交换、RSA 数字签名
• ECDHE 密钥交换、RSA 数字签名
• ECDHE 密钥交换、ECDSA 数字签名

实现方式 1：

1. Visitor 给出协议版本号、一个客户端随机数（Client random），以及客户端支持的加密方法
2. Server 确认双方使用的加密方法，以及一个服务器生成的随机数（Server random）
3. Server 发送数字证书给 Visitor
4. Visitor 确认数字证书有效（查看证书状态且查询证书吊销列表），并使用信任的 CA 的公钥解密数字证书获得 Server 的公钥，然后生成一个新的 46 字节随机数（称为预备主密钥 Pre-master secret），并使用 Server 的公钥加密预备主密钥发给 Server
5. Server 使用自己的私钥，解密 Visitor 发来的预备主密钥
6. Visitor 和 Server 双方都具有了(客户端随机数 + 服务端随机数 + 预备主密钥)，它们两者都根据约定的 加密方法，使用这三个随机数生成对称密钥——主密钥（也称为对话密钥 session key），用来加密后续的对话过程
7. 在双方验证完 session key 的有效性之后，SSL 握手机制就算结束了。之后所有的数据只需要使用“对话密钥”(此密钥并不是的 session key，而是由其通过计算得到)加密即可，不再需要多余的加密机制
   注意：
8. 在 SSL 握手机制中，需要三个随机数（客户端随机数 + 服务端随机数 + 预备主密钥）
9. 至始至终客户端和服务端只有一次非对称加密动作——客户端使用证书中获得的服务端公钥加密预备主密钥。
10. 上述 SSL 握手机制的前提单向验证，无需验证客户端，如果需要验证客户端则可能需要客户端的证书或客户端提供签名等。
11. Server 和 Visitor 通信，Server 把数字证书发给 Visitor，最关键的一点是 Visitor 要保证证书的有效性， 通过查看证书状态并去 CA 的吊销列表查看 Server 的证书是否被吊销。只有 Server 的证书可用了，才保证了第一环节的安全性
12. RSA 密钥交换有一个很大的问题：没有前向安全性 Forward Secrecy。这意味着攻击者可以把监听到的加密流量先存起来，后续一旦拿到了私钥，之前所有流量都可以成功解密

实现方式 2

目前大部分 HTTPS 流量用的都是 ECDHE 密钥交换。ECDHE 是使用椭圆曲线（ECC）的 DH（Diffie-Hellman）算法

前图中的 Server DH Parameter 是用证书私钥签名的，客户端使用证书公钥就可以验证服务端合法性。相比 RSA 密钥交换，DH 由传递 Premaster Scret 变成了传递 DH 算法所需的 Parameter，然后双方各自算出 Premaster Secret

对于这种情况，由于 Premaster Secret 无需交换，中间人就算有私钥也无法获得 Premaster Secret 和 Master Secret。当然，使用 ECDHE 后，虽然中间人拿到私钥也无法解密之前的流量，但可以实施 MITM 攻击来解密之后的流量，所以私钥还是要保管好。

相比 RSA 既可以用于密钥交换，又可以用于数字签名；ECC 这边就分得比较清楚了：ECDHE 用于密钥交换，ECDSA 用于数字签名

1.8.4 HTTPS

HTTPS 协议：就是“HTTP 协议”和“SSL/TLS 协议”的组合。HTTP over SSL 或 HTTP over TLS ，对 http 协议的文本数据进行加密处理后，成为二进制形式传输

1.8.4.1 HTTPS 结构

1.8.4.2 HTTPS 工作的简化过程

• 客户端发起 HTTPS 请求

  • 用户在浏览器里输入一个 https 网址，然后连接到服务器的 443 端口

• 服务端的配置

  • 采用 HTTPS 协议的服务器必须要有一套数字证书，可以自己制作，也可以向组织申请。区别就是自己颁发的证书需要客户端验证通过，才可以继续访问，而使用受信任的公司申请的证书则不会弹出提示页面。这套证书其实就是一对公钥和私钥

• 传送服务器的证书给客户端

  • 证书里其实就是公钥，并且还包含了很多信息，如证书的颁发机构，过期时间等等

• 客户端解析验证服务器证书

  • 这部分工作是有客户端的 TLS 来完成的，首先会验证公钥是否有效，比如：颁发机构，过期时间等等，如果发现异常，则会弹出一个警告框，提示证书存在问题。如果证书没有问题，那么就生成一 个随机值。然后用证书中公钥对该随机值进行非对称加密

• 客户端将加密信息传送服务器

  • 这部分传送的是用证书加密后的随机值，目的就是让服务端得到这个随机值，以后客户端和服务端 的通信就可以通过这个随机值来进行加密解密了

• 服务端解密信息

  • 服务端将客户端发送过来的加密信息用服务器私钥解密后，得到了客户端传过来的随机值

• 服务器加密信息并发送信息

  • 服务器将数据利用随机值进行对称加密,再发送给客户端

• 客户端接收并解密信息

  • 客户端用之前生成的随机值解密服务段传过来的数据，于是获取了解密后的内容