标题:
加密算法使用场景以及HTTPS加密机制
[打印本页]
作者:
look_w
时间:
2019-2-19 16:27
标题:
加密算法使用场景以及HTTPS加密机制
消息摘要算法、对称加密算法、非对称加密算法之应用场景
上一篇文章主要向大家介绍了三种加密算法和它们的特点,这篇文章作为上一篇文章的续就来讲讲它们的应用场景,也顺带着讲一下HTTPS相对于HTTP的安全性是做了哪些防护。
数字信封
首先假定一个场景,应用的开发需要加密大量的数据,且要密钥需要在使用过程中传输。在这种情况下使用非对称加密能够保证分发密钥的安全性,因为只需要将公钥分发给用户,私钥保存在自己手里,只要不被盗窃走或者被破解是没有问题的。但是别忘了,这里的要求是对大量的数据进行加密,这种情况下使用非对称加密会使得加密的时间变得漫长,所以这里显然是不适合非对称加密的。再来看看对称加密,速度加快了,这很好,但是别忘了密钥传输的问题,一旦密钥在传输过程中被截取,数据的安全性也无从谈起了,这就必须专门安排安全的信道给密钥,似乎也不是一个很好的方法。
这个情况下不同解密算法的灵活结合就成了更为合理的解决方式。数字信封这种结合的一个优秀典范。数字信封采用对称加密算法加密数据,非对称加密算法加密对称密钥的方式解决了以上的问题,也适用于一些其他的加密场景。以下是其示意图。
SSL协议
SSL(Secure Sockets Layer)协议是HTTPS协议的安全性基石,相较于HTTP,HTTPS正是加入了SSL层来确保数据传输的安全性。以下通过模拟几种数据传输过程来了解SSL协议。
Round 1
客户端 >>>> 服务器:你好!
服务器 >>>> 客户端:你好!这是我们传输过程中需要的公钥{公钥|RSA}
客户端 >>>> 服务器:收到公钥,让我们来验证一下,这是我加密的一个随机数,解出来给我看看。{加密过的随机数}[公钥|RSA]
服务器 >>>> 客户端:{解密过的随机数}[私钥|RSA]
客户端 >>>> 服务器:验证成功,这是我的账号和密码,给我看看我的私密日记{用户名,密码}[公钥|RSA]
服务器 >>>> 客户端:{我喜欢xxx}[私钥|RSA]
这种加密方式粗看起来没有问题,数据都是加密后再传输,但是仔细想想,似乎有很大的问题。首先回忆一下,RSA的公钥是共享的,一旦数据在传输过程中被抓取,再通过公开的公钥进行解密,数据的安全性就不能得到保障了。在数据传输过程中,单独使用非对称加密似乎是不可靠的,这种情况下上面介绍的数组信封就起作用了。
Round 2
<pre><code>
客户端>>>>服务器:你好!
服务器>>>>客户端:你好!这是我们传输过程中需要的公钥{公钥|RSA}
客户端>>>>服务器:收到公钥,让我们来验证一下,这是我加密的一个随机数,解出来给我看看。{加密过的随机数}[公钥|RSA]
服务器>>>>客户端:{解密过的随机数}[私钥|RSA]
客户端>>>>服务器:验证成功,这是数据传输过程中需要用到的对称密钥,{对称密钥}[公钥|RSA]
服务器>>>>客户端:{收到密钥}[密钥|AES]
客户端>>>>服务器:这是我的银行卡号和密码,给我查查余额{卡号,密码}[密钥|AES]
服务器>>>>客户端:{你的银行卡余额,五毛}[密钥}|AES]
</code></pre>
相比Round1,Round2的数据传输的安全性得到了保障,只要不发生密钥被盗或者破解,就不会出现数据安全问题,但是这样就真的安全了吗?来看看Round3。
Round 3
<pre><code>客户端>>>>黑 客:你好!
黑 客>>>>客户端:你好!这是我们传输过程中需要的公钥{公钥|RSA}
客户端>>>>黑 客:收到公钥,让我们来验证一下,这是我加密的一个随机数,解出来给我看看。{加密过的随机数}[公钥|RSA]
黑 客>>>>客户端:{解密过的随机数}[私钥|RSA]
客户端>>>>黑 客:验证成功,这是数据传输过程中需要用到的对称密钥,{对称密钥}[公钥|RSA]
黑 客>>>>客户端:{收到密钥}[密钥|AES]
客户端>>>>黑 客:这是我的银行卡号和密码,给我查查余额{卡号,密码}[密钥|AES]
黑 客>>>>客户端:嘿嘿,你上当了</code></pre>
所以在实际的数据传输中存在一个问题,当前的服务器真的是真正的服务器吗?怎么才能确定这个服务器的身份?这个时候,数字证书的作用就显现出来了。大家都知道,使用HTTPS需要申请数字证书,这个证书是保证HTTPS安全数据传输的基石。这个证书就是SSL证书,在这个证书中包含以下内容:
证书的发布机构
证书的有效期
公钥
证书所有者(Subject)
签名使用的算法
指纹以及指纹使用的算法
在了解数字证书的内容后,下面一轮模拟数据传输将会使用到上一篇文章讲到的三种加密方式,也能大致了解到HTTPS的安全机制。
Round 4
<pre><code>客户端>>>>服务器:你好!
服务器>>>>客户端:你好!这是我的数字证书
客户端>>>>服务器:我已收到并验证了数字证书的合法性,验证你是证书的合法拥有者,这是证书的公钥加密的随机数{随机数}[公钥|RSA]
服务器>>>>客户端:{解密过的随机数}[私钥|RSA]
客户端>>>>服务器:验证成功,这是数据传输过程中需要用到的对称密钥,{对称密钥}[公钥|RSA]
服务器>>>>客户端:{收到密钥}[密钥|AES]
客户端>>>>服务器:这是我的银行卡号和密码,给我查查余额{卡号,密码}[密钥|AES]
服务器>>>>客户端:{你的银行卡余额,一个亿}[密钥}|AES] </code></pre>
在Round4,服务器发送给客户端的数字证书中,包含数字摘要算法产生的指纹以及所使用的数字摘要算法,这部分使用来验证数字证书的完整性以及合法性的。如果指纹(可以认为是MD5或者SHA对证书加密产生的字符串)能够与客户端对证书加密产生的指纹对应(使用证书中的数字摘要算法对证书加密),就能够证明证书没有被篡改过,其合法性也就得到验证。一下的步骤就与上面介绍的数字信封类似了。通过以上的模拟,能够知道使用SSL协议的HTTPS协议既能保证数据传输中的安全,也能保证客户端与服务器连接的安全。
总结
HTTPS虽然安全,但不能完全保护数据安全,它能够做的是在数据传输过程中保护数据的安全,服务器和客户端中数据安全也是需要注意的。
通过这两篇文章的介绍,大家能够大体了解到现在主要的加密方式以及它们的使用场景,也稍微接触到了HTTPS的安全加密机制,虽然这在开发中的使用机会不大,但能够了解到这些优秀的机制,以后在有加密需求的时候也能够多一些思路。
欢迎光临 电子技术论坛_中国专业的电子工程师学习交流社区-中电网技术论坛 (http://bbs.eccn.com/)
Powered by Discuz! 7.0.0