都2022年了,还不会对称加密和非对称加密算法?

2022-01-19 13:46:31 浏览数 (1)

0 前言

下单做一次支付,若还是使用HTTP协议,可能会被黑客盯上。 你发送个请求,买娃娃,但该网络包被截获,于是在服务器回复你之前,黑客先假装自己就是电商网站,然后给你回复一个假消息:“好呀,来把银行卡号、密码拿来。” 这时你真把银行卡密码发给它,就中招了。

怎么解决这种问题?

一般想法就是加密:

  • 对称加密 加密、解密使用相同密钥。因此,要保证安全性,密钥就要做好保密。
  • 非对称加密 加密使用的密钥和解密使用的密钥不同:
    • 一把作为公开的公钥
    • 另一把作为谁都不给的私钥 公钥加密的信息,只有私钥才能解密。私钥加密的信息,只有公钥才能解密。

因为对称加密算法相比非对称加密算法来说,效率较高,性能也好,所以常用对称加密。

1 对称加密

假设你和电商网站约定一个密钥,你发请求时候用该密钥进行加密,电商网站用同样密钥进行解密。 就算黑客中途截获你的请求,但它没有密钥,破解不了。

但双方如何约定密钥?

若密钥在互联网上传输,很可能被截获,黑客可以假装不知,静静地等你们两个交互。你们之间互通的任何消息,它都能截获并且查看,等于你把银行卡账号和密码发出来。

我们经常能看到,特工破译的密码会有个密码本,截获无线电台,通过密码本就能将原文破解出来。 怎么把密码本给对方呢?那就只能通过线下传输。

比如,你和电商网站偷偷约定时间地点,它给你一个纸条,写着你们两个的密钥,然后说以后就用这个密钥在互联网购物了。 你们接头时,也要先约定一个口号,如“天王盖地虎”,口号对上,才把纸条给对方。 但“天王盖地虎”也还是对称加密密钥,也存在如何把“天王盖地虎”约定成口号的问题。而且谍战剧中一对一接头还可以,但互联网用户太多,显然行不通。

2 非对称加密

所以,只要是对称加密,就会陷入死循环,只能依赖非对称加密。

  • 非对称加密的私钥放在电商网站,不会在互联网上传输,保证该秘钥的私密性
  • 但对应私钥的公钥,可在互联网随意传播,只要电商网站把这个公钥给你,你们就能愉快互通

比如你用公钥加密,说“我要买娃娃”,黑客在中间就算截获这个报文,因为它没有私钥,解不开,所以该报文能顺利到达电商网站,电商网站再用私钥解密这个报文,然后回复,“那给我银行卡和支付密码吧”。

其实还是有问题的。回复的这句话,是电商网站拿私钥加密的,互联网上人人都可以把它打开,当然包括黑客。

那电商网站可以拿公钥加密吗?

不能,因为它自己的私钥只有自己知道,谁也解不开。

而且黑客也能模拟发送“我要买娃娃”,因为它也拿得到电商网站的公钥。 所以一对公钥私钥远远不够,客户端也要有自己的公钥和私钥,并且客户端要把自己的公钥,给电商网站。

这样,客户端给电商网站发送时,用电商网站的公钥加密。 而电商网站给客户端发消息时,使用客户端的公钥。这样就算有黑客企图模拟客户端获取一些信息或半路截获回复信息,由于没有私钥,就无法打开这些信息。

数字证书

不对称加密也面临同样问题,如何将不对称加密的公钥给对方:

  • 放在一个公网地址上,让对方下载
  • 在建立连接时,传给对方

俩方案有相同的问题:作为一个普通用户,如何甄别别人给你的公钥是对的。 会不会有人冒充电商网站,发给你一个它的公钥。接下来,你和它所有的互通,看起来都是没有任何问题的。毕竟每个人都可以创建自己的公钥和私钥。

例如,我自个儿搭建了一个网站xxxsite,先创建私钥:

代码语言:javascript复制
openssl genrsa -out xxxsiteprivate.key 1024

然后,再根据这个私钥,创建对应的公钥。

代码语言:javascript复制
openssl rsa -in xxxsiteprivate.key -pubout -outcliu8sitepublic.pem

这时候就需要权威部门介入,就像每个人都可以自己打印简历,说自己是谁,但最后还是要有公安局证明的比如身份证,才能证明你是你。这个由权威部门颁发的称为证书(Certificate)。

证书

里面有啥:

  • 公钥 最重要的
  • 证书的所有者 就像身份证上有你的姓名和身份证号,说明这个身份证是你的
  • 证书的发布机构和证书的有效期 就像身份证上的机构是哪个区公安局,有效期到xx年

如何生成证书?

会不会有人假冒权威机构颁发证书呢?就像有假身份证一样。 生成证书需要发起一个证书请求,然后将该请求发给一个权威机构去认证,这个权威机构称为CA( Certificate Authority)。

证书请求可以通过这个命令生成。

代码语言:javascript复制
openssl req -key xxxsiteprivate.key -new -out cliu8sitecertificate.req

将这个请求发给权威机构,权威机构会给这个证书卡一个章,我们称为签名算法。 怎么签名才能保证是真的权威机构签名的呢? 用只掌握在权威机构里的东西签名才行,这就是CA的私钥。

签名算法

对信息做一个Hash计算,得到一个Hash值,该过程是不可逆的,即无法通过Hash值得出原信息内容。 把信息发送出去时,把这个Hash值加密后,作为一个签名和信息一起发出去。

权威机构给证书签名的命令是这样的。

代码语言:javascript复制
openssl x509 -req -in xxxsitecertificate.req -CA cacertificate.pem 
	-CAkey caprivate.key -out xxxsitecertificate.pem

该命令会返回Signature ok,xxxsitecertificate.pem就是签过名的证书。CA用自己的私钥给电商网站的公钥签名,就相当于给电商网站背书,形成了外卖网站的证书。

该证书的内容:

代码语言:javascript复制
openssl x509 -in xxxsitecertificate.pem -noout -text 
  • Issuer 证书是谁颁发的
  • Subject 证书颁发给谁
  • Validity 证书期限
  • Public-key 公钥内容
  • Signature Algorithm 签名算法

你不会从电商网站得到一个公钥,而是会得到一个证书,该证书有个发布机构CA,你只要得到这个发布机构CA的公钥,去解密电商网站证书的签名,解密成功,Hash也对的上,就说明这个电商网站的公钥没问题。

想验证证书,就需要CA的公钥,但怎么确定CA的公钥就是对的?

所以,CA的公钥也需要更牛的CA给它签名,然后形成CA的证书。 要想知道某CA的证书是否可靠,要看CA的上级证书的公钥,能不能解开这个CA的签名。 就像你不信区公安局,可以打电话问市公安局,让市公安局确认区公安局合法性。层层上去,直到全球皆知的几个著名大CA,称为root CA,做最后背书。

HTTPS的工作模式

非对称加密在性能上不如对称加密,能将结合二者优点呢? 如,公钥私钥主要用于传输对称加密的秘钥,而真正的双方大数据量的通信都是通过对称加密进行的。 可以的!这就是HTTPS协议的总体思路。

登录一个电商网站时,由于是HTTPS,客户端会发送Client Hello消息到服务器,以明文传输TLS版本信息、加密套件候选列表、压缩算法候选列表等信息。还有一个随机数,在协商对称密钥的时候使用。

这就类似在说:“您好,我想购物,但你要保密我买的啥。这是我的加密套路,再给你个随机数,你留着。”

然后,电商网站返回Server Hello消息,告诉客户端,服务器选择使用的协议版本、加密套件、压缩算法等,还有一个随机数,用于后续的密钥协商。

这就像在说:“您好,保密没问题,你的加密套路还挺多,咱们就按套路2吧,我这里也有个随机数,你也留着。”

然后,电商网站会给你一个服务器端的证书,然后说:“Server Hello Done,我这里就这些信息了。”

你当然不相信这个证书,于是你从自己信任的CA仓库中,拿CA的证书里面的公钥去解密电商网站的证书:成功,则说明电商网站可信。 这个过程中,你可能会不断追溯当前CA的上级,直到一个授信的CA。

证书验证完后,觉得这个电商网站可信,于是客户端计算产生随机数字Pre-master,发送Client Key Exchange,用证书中的公钥加密,再发送给服务器,服务器可以通过私钥解密出来。

至此,无论是客户端or服务器,都有三个随机数:自己的、对端的及刚生成的Pre-Master随机数。 通过这三个随机数,可以在客户端和服务器产生相同的对称密钥。

有了对称密钥,客户端就可以说:“Change Cipher Spec,咱们以后都采用协商的通信密钥和加密算法进行加密通信了。”

然后发送一个Encrypted Handshake Message,将已商定好的参数等,采用协商密钥进行加密,发送给服务器用于数据与握手验证。

同样,服务器也可以发送Change Cipher Spec:“没问题,咱们以后都采用协商的通信密钥和加密算法进行加密通信了”,并且也发送Encrypted Handshake Message的消息试试。当双方握手结束之后,就可以通过对称密钥进行加密传输了。

该过程除了加密解密之外,其他过程和HTTP一样,过程也非常复杂。

上面过程只包含HTTPS的单向认证,即客户端验证服务端的证书,是大部分场景,也能在更加严格安全要求的情况下,启用双向认证,双方互相验证证书。

重放与篡改

有了加密和解密,黑客截获了包也打不开了,但它能发送N次。这个往往通过Timestamp和Nonce随机数联合起来,然后做一个不可逆的签名来保证。

Nonce随机数保证唯一,或者Timestamp和Nonce合起来保证唯一,同样的,请求只接受一次,于是服务器多次受到相同Timestamp和Nonce,则视为无效即可。

如果有人想篡改Timestamp和Nonce,还有签名保证不可篡改性,如果改了用签名算法解出来,就对不上了,可以丢弃了。

总结

加密分对称加密和非对称加密。对称加密效率高,但是解决不了密钥传输问题;非对称加密可以解决这个问题,但是效率不高。

非对称加密需要通过证书和权威机构来验证公钥的合法性。

HTTPS是综合了对称加密和非对称加密算法的HTTP协议。既保证传输安全,也保证传输效率。

0 人点赞