什么是对称加密非对称加密、密钥交换、数字签名、证书
2023-3-15
·
hexer

对称式加密

加密和解密都使用同一把密钥

网络上传输的数据是加密的,第三方窃听者甚至无法破解

缺点在于需要交换密钥

解决密钥交换的方式是密钥交换算法非对称加密算法

密钥交换算法

前提:单向散列函数,给出F(x)和F,无法推出x

假设有三个人,Alice,Bob和Hack(第三方中间人),Hack现在想窃听Alice和Bob的聊天信息

假设Alice和Bob想出两个数字A和B想出两个数字A和B,且确定用G作为生成元(三方都知道)

Alice使用A和G生成AG

Bob使用B和G生成BG

网络数据交换,Alice获得BG,Bob获得AG,Hack获得AG和BG(此时Hack知晓AG,BG和G,但是由于单向散列函数的特性无法推出A和B)

Alice使用BG和A通过运算手段获得ABG

Bob使用AG和B通过运算手段获得ABG

这样Alice和Bob得到了他们共有的限定的数

Hack因为无法确定A或者B所以无法确定ABG

flowchart LR
subgraph 生成元
G
end
subgraph Alice和Bob都知晓
ABG
end
subgraph Alice
A --> G -->|生成| AG -->|给Bob| Bob知道AG和BG和B -->|通过算法使用AG和B生成ABG| ABG
end
subgraph Bob
B --> G -->|生成| BG -->|给Alice| Alice知道BG和AG和A -->|通过算法使用BG和A生成ABG| ABG
end

中间人攻击

对于密钥交换算法,Hack想出了一种方式来破解

不再是窃听,而是直接冒充Alice和Bob的身份进行交流

非对称加密

非对称加密的思路是,将加密密钥和解密密钥分开,公钥用于加密,私钥用于解密

只把我的公钥给对方,对方用我的公钥,到本地用自己的私钥解密

可以这样想,公钥是锁,私钥是钥匙,把锁给别人,钥匙留在自己这里,这样方便理解

常见的RSA算法就是典型的非对称加密算法

实际应用中非对称加密的运算速度要慢于对称性加密,所以在传输大量数据的时候,非对称加密传输的先是对称加密的密钥,然后通过对称加密密钥来传输数据,这样效率更高

sequenceDiagram
    Alice->>Bob: 公钥加密{对称加密密钥}之后发送给对方
    Bob->>Bob: 解密后获得{对称加密密钥}
    Bob->>Alice: 使用对称及加密密钥发送数据
    Alice->>Alice: 接收,使用{对称加密密钥}解密
    Alice->>Bob: 再次加密数据,发送
    Bob-->>Alice: 循环往复

注意,非对称加密也无法防范中间人攻击,比如Hack拦截了Alice的公钥,然后伪装Bob给Alice发信息

数字签名

非对称加密的私钥其实也可以用来加密,然后使用公钥解密,数字签名和非对称加密有点类似只不过完全颠倒

用你的私钥将数据发送出去,这就是数字签名

数字签名的意义在于,验证身份,能解开私钥加密过的数字签名,那么也就确定了你的身份

流程大致是:

  • 生成公钥和私钥,公钥发出去

  • 你将数据和数字签名(加密后的数据)发出去

  • 对方接收数据和数字签名并验证

数字签名同时有着确认完整性的功能,加密的数据其实是全部数据的hash值

这里有个小问题,在使用数字签名认证了身份后,之后的传输数据还需要附带数字签名吗,数字签名的效果是确认发送方的身份,需要密钥解密,我们第一次解密得到的是对称式加密密钥,之后我们用来加密的就是对称式加密了,解不开就说明遭到中间人攻击,所以之后无需数字签名

sequenceDiagram
	Alice->>Alice: 生成公钥和私钥
    Alice->>Bob: Alice的公钥发给Bob
    Alice->>Bob: 将数据和数字签名(加密后的数据)发出去
    Bob->>Bob: 接收数字签名,确认身份,解密数据,获得对称式加密密钥
    Bob->>Bob: 用对称式加密密钥加密数据
    Bob->>Alice: 传输
    Alice-->>Bob: 循环往复

假设中间人修改了明文数据,那么解密之后的数字签名与明文不符

如果中间人修改了数字签名,那么解密之后数字签名极可能乱码无法解读

如果中间人同时修改了数字签名明文数据,那么对方的公钥无法正确解开,哪怕解开了数据返回的时候的数字签名也不是中间人的

数字签名从一定程度上可以认定数据发送方的身份,之所以是一定程度上,是因为公钥的分发过程还是有可能出问题,可能在最开始公钥就被中间人修改了

数字签名是一种用于身份认证的方式,但是最开始的公钥分发就有可能出问题…对于公钥分发,要先确定你的身份是真的,但是数字签名就是用来解决身份认证问题的…陷入死循环了…

我们需要找一个大家都信任的第三方机构,来认证你的身份,如此公钥分发便安全许多

公钥证书

证书其实就是公钥+签名,由第三方受信任的机构(certificate authority,简称CA)颁发

流程如下:

一般来讲浏览器会预先安装几个正规机构的证书,用于确认身份,所以证书的认证还是可信的,所以不要乱装不正规浏览器

现在的网站大多使用的是HTTPS协议,就是在 HTTP 协议和 TCP 协议之间加了一个 SSL/TLS 安全层。在你的浏览器和网站服务器完成 TCP 握手后,SSL 协议层也会进行 SSL 握手交换安全参数,其中就包含该网站的证书,以便浏览器验证站点身份。SSL 安全层验证完成之后,上层的 HTTP 协议内容都会被加密,保证数据的安全传输。

补充

安全技术最多只能保证技术上无问题,但是不代表着完全安全,第三方认证机构也不一定完全安全

HTTPS认证流程

sequenceDiagram
	浏览器->>服务器: 发出请求
	服务器->>浏览器: 用私钥加密网页后,加上本身的数字签名一起发送
	浏览器-->>CA: 浏览器根据CA签证去找CA确定网站信息,如果没有则网页数据无法加密
	CA-->>浏览器: 返回网站的证书(公钥+签名)
	浏览器-->浏览器: 验证证书是否正常
	浏览器->>服务器: 交互信息,循环往复
   

RSA公钥私钥可否互换

原理上是可行的,但是实际上由于一些生成算法和其他情况,不可行

例如一种情况:公钥就是用私钥生成的,公开私钥=公开公钥和私钥

参考: