【安全】对称加密、非对称加密、数字签名和CA是什么？

今天学习了关于网络通信过程中的安全相关的知识，还有一些基础的概念，现做以总结，博客的图示都是自己画的，如果能够有助于你的理解，请点个赞收藏一下~~

目录

对称加密

对称加密的一方（比如小蓝）用秘钥 Key给消息 加密；另一方（比如老白）用同一个秘钥Key解密。

这有一个问题：当一方生成了秘钥 Key 之后得把 Key分享给另一方。但是通信隧道中途很可能有人窃听到 Key，窃听者就可以假扮双方中的任何一方与另一方通信。这叫中间人攻击。

非对称加密算法

非对称加密算法利用成对的两个秘钥：K1 和 K2。公钥用来公布给所有人，私钥用来加密数据。特点是用私钥加密数据，只能用对应的公钥解密，反之亦然。

这样一来，通信中一方，比如小蓝，生成密钥对K1,K2，将K1作为私钥，K2作为公钥传输给老白。老白得到K2后，就可以用公钥来解密小蓝发的信息。

但是这同样也存在问题，中间人如果能够截获K2，那么他就可以伪造新的公钥，比如N2，来欺骗老白，因此同样存在安全问题。

图文版过程如下图所示，中间人截获小蓝的公钥K2，并生成自己的公钥私钥，将自己的公钥N2公布给老白，并欺骗他，这是小蓝的公钥。

如此一来，对于小蓝来说，中间人的角色是老白，对于老白来说，中间人的角色是小蓝。

中间人一人分饰两角色，可以对小蓝和老白的通信内容进行查看甚至篡改。

数字签名和CA

因此，为了使得老白获得的公钥确实是小蓝的而不是经过偷梁换柱后的中间人的，引入了数字签名和CA（权威机构，可以理解为说话很有信服力的机构）。

数字签名的具体步骤是：

1. 小蓝用自己的公钥加上ID，ID包含自己的身份信息或者域名，得到一个CSR（certificate signing request）
2. 将这个CSR发给权威的证书机构CA（certificate authority）
3. CA进行一个签名的操作，具体是：用自己的私钥加密小蓝的CSR，得到数字签名（digital signature）
4. 数字签名加上小蓝的CSR得到CRT（CA signed certificate），明文发给小蓝，小蓝有身份证啦~

图文版的过程如下：

STEP1：小蓝用自己公钥加上ID生成CSR给CA-1这个权威机构

STEP2:CA-1得到小蓝CSR之后，用自己的私钥加密CSR，得到signature，这又被称为数字签名

** STEP3:CA-1将数字签名和CSR一同合为CRT（CA signed certificate）明文发给小蓝**

在进行HTTPS通信时，小蓝向对方展示自己的CRT，这就像是权威的身份证，证明自己的身份

如下图所示，通信时，小蓝向老白展示了自己的CRT，老白拿到CRT之后，会进行一个CSR的比对，具体过程是：

1. 从CRT中拿到小蓝的CSR和经过CA加密后的C1(CSR)
2. 由于老白有CA的证书，因此可以解密C1(CSR)得到小蓝的CSR1
3. 比对CSR1 和CSR是否相等

证书的信任链

由此可见，经过权威机构签名后，就相当于身份证上签了德高望重的人名了，这样出去和人谈话别人也会相信你，但是如果上面例子中所述的CA-1大家都不信任怎么办？

可以找一个大家都信任的CA，这里姑且叫他大boss好了，用大boss的私钥在上述不受信任的CA-1身份证上签名，如果浏览器或者OS里安装了大boss的公钥，就可以验证“CA-1的身份证是大boss确认并且签过名的”,如果大boss也不被通信过程中的对方信任，就可以再找一个CA来签名来确认大boss身份，这个过程可以不断递推，从而形成一个信任链（trust of chain）

根身份证和自签名

根身份证在信任链的顶端，根身份证由自己签名，具体的过程是：

1. 自己生成一对密钥，私钥K1,公钥K2
2. 创建自己的CSR，等于K2+ID
3. 用自己的密钥加密CSR得到signature，然后将CSR明文和signature一起发布

我们知道HTTPS等于HTTP+TLS/SSL，举一个例子，当我们通过浏览器访问银行的网页时，这里会有两个验证的过程，一个是浏览器验证银行身份，一个是银行验证浏览器身份。

浏览器验证银行身份时：在双方HTTPS服务建立安全连接过程中，银行会把自己的CRT（身份证）发给浏览器，浏览器使用内置CA进行一个身份的验证

银行验证浏览器的用户身份：浏览器展示银行HTTPS服务发来的登录页面，用户在这个页面内输入账号信息，银行的HTTPS基于此来验证用户身份

而有时候的通信双方都是程序，没有人就不需要输入账户信息，这时候就需要双方都通过TLS身份证来验证。比如在K8S集群中，来自客户端控制程序kubectl程序或者各个节点运行的kubelet进程，再或者控制平面的成员组件在向api-server发出请求时，必须向集群网关api-server进行身份验证，否则将被视为匿名用户。

API-server程序自动启动的认证方式是Service Account令牌认证(简称sa)，该认证方式可以通过--apiserver-account-key-file加载签署承载令牌的密钥文件，未指定时将使用API server自己的TLS私钥。