• 加密类型及其相关算法


    TCP/IP 在设计的最初并没有花太多时间来考虑它的安全性。随着互联网普及下,最终发现在这种完全开放的结构体系下,网络攻击、网络安全问题层出不穷。例如:alex 要给 bob相互发送邮件,这中间有多少的威胁。

    image-20210103142535427

    假如 Alex 和 bob从来没见过面,在互联网上两台从来没见过的机器相互通信是非常常见的事。例如某宝购物,任何人使用任何机器下单,这就是两台从未见过面的主机进行通信。因此,两台从来没有见过的主机进行通信,安全上会面临哪些风险?

    例如,某商业行为,双方通过电脑进行通信洽谈,设计到商业机密的时候,TCP/IP并不提供加密功能,完全是明文传输。那这中间经过的通信设备都能一目了然。

    • 明文传输(ftp,http,smtp,telnet)

    上面的协议都是明文传输的,只要抓取数据包,别人就能一目了然所有的传输信息。因此机密性就无从得到保证。

    假如:alex 和 bob 并不怕别人知道他们之间的小秘密,这样是不是就可以毫无顾忌的进行通信呢?

    image-20210103143842812

    如上图,当通过明文传输时,信息就有可能被恶意篡改,获取到的信息,很可能是别篡改后的信息。无法保证准确性,因此,数据在互联网上传输的时候,不应该也不能够被其他人任意的非法篡改掉,这就要求数据的完整性要得到保证。

    当别人篡改,当数据在传输过程中由于信号本身的问题导致错乱也好,任何时候得到的数据和对方发过来的数据有不一致情况的时候,都应该拒绝使用这份数据。这样才能保证数据的完整性。但数据完整性并不意味着全部的问题。从来没见过面的两台主机,比如:某宝下单的时候,有人宣称:我就是某宝,你来我这里访问吧。当你去访问后,才发现对方的服务器是冒名顶替的。

    image-20210103144809931

    因此,必须还有一种机制来保证,我们所访问的那台主机从来没有通信过的主机在我们和它建立通信的时候,能够有一种有效的手段去保证它就是它所声称的那台主机。(经典问题:怎么证明你就是你?当然是取出身份证扇他脸。)而这个过程就是身份验证的问题。上面所暴露出来的三个问题总结如下:

    • 机密性:不能明文传输,会被恶意篡改;
    • 完整性:通信的双方获得的信息是否一致;
    • 身份验证:你怎么证明你就是声称的主机。

    以上三个问题恰恰反应当前互联网上所面临的安全风险当中诸多应该解决的问题。

    (1)如何保证数据的机密性?

    一般通过转换规则来实现:

    plaintext --> 转换规则 --> ciphertext
    ciphertext --> 转换规则 --> plaintext
    

    image-20210103150242578

    想象一下,如果别人得知了转换规则,如果通过其他手段窃取到了这个转换规则算法本身(转换规则可以直接理解为算法)。那这时候怎么办?换一个转换规则(算法)?

    互联网安全体系结构中的一种基本法则:保证数据机密性最核心的不是算法本身,而是密钥。因此需要靠密钥保证安全性。别人可以得到转换规则,但是有转换规则不知道密钥是什么,依然无法将密文还原为明文。为什么要采用这样的设计?换一个密钥很简单,而换一个算法是可想而知的。 设计一个算法需要很长的时间,要考虑非常多的因素。 所以算法固然很重要,但是就算别人知道了算法,也不完全把安全性本身完全依赖于算法,而是依赖于密钥来实现,因为换一个密钥要比换一个算法简单的太多。

    机密性保证的最早实现算法:对称加密。提供加密本身,并且要求用户提供一个密钥以后能够结合密钥和算法,将明文转换为密文,反之所以把它称为对称加密,加密和解密使用的是同一个密钥。对称加密的好处在于:加密和解密速度非常快。但是其安全性几乎完全依赖于密钥,因为很多算法是公开的。

    image-20210103152113359

    如图,当 A 和B 通信使用的密钥是 “abc”,那当 A 和 C 通信的时候是否也采用密钥为:“abc” 来通信呢?

    假如,A 和 C 也采用密钥“abc”来通信,C 就得到了密钥,随时都可以破解 A - B 的通信内容,这显然是不可以的。于是问题就出现了,A就必须为每个用户维护一个密钥,假如A通信达到50、100个人的时候怎么办?需要记住50、100个密钥。 当通信对象很多的前提下,没办法对密钥进行管理。 对称加密算法在一定程度上解决了数据机密性的问题,却没办法帮用户解决密钥有效管理的问题。

    (2)数据完整性

    image-20210103161018881

    如何保证发送方和接收方的消息是一致的?这种加密算法叫:单向加密算法。

    单向加密算法:提取数据特征码(数据特征码是由数据通过算法计算得到)。

    回到上面的图,现在的问题是李雷和韩梅梅之间通信如何基于单向加密算法来保证数据完整性呢?

    image-20210103161642339

    数据特征码特征如下:

    • 输入相同,输出必然一致。
    • 雪崩效应:输入的微小改变,将会引起结果的极大改变,主要防止暴力破解。
    • 定长输出:无论原始数据是多大,结果大小都是相同的。
    • 不可逆:无法通过特征码还原原来的数据。

    有了特征码还是无法防止中间人攻击:

    1. 李雷发送消息给韩梅梅 plaintext:footprint(李雷明文:李雷明文特征码)
    2. 张三从中截取了李雷发送给韩梅梅的消息并进行篡改 plaintext:footprint(张三明文:张三明文特征码)
    3. 韩梅梅接收到张三篡改的消息(韩梅梅并不知道张三从中作梗),通过相同的算法计算出特征码和张三的特征码对比,发现特征码一致,韩梅梅就深信这是李雷发过来的消息(韩梅梅只知道消息是从李雷发送过来的,而且计算比较特征码没有问题)。

    如果发生上述事件,张三就躲在角落偷偷笑了。

    ​ 显然,数据机密性这种手段并不能保证机密性本身,还需要借助于其他机制,如何保证张三不能随意篡改或者篡改后的数据韩梅梅能够发现?

    ​ 数据本身的机密性并不关键,李雷生成了这段明文(plaintext:footprint)如何才能保证特征码不被别人发现,这里就使用了特征码加密的方式(plaintext:),韩梅梅假设知道李雷这段特征码是加密的,韩梅梅就会利用加密时候使用的密钥对这段数据进行解密,只要能解密就表示特征码没有被篡改过,这里李雷加密和解密的密钥或密码只有他两知道。假如张三抓取到李雷的数据篡改数据(plaintext2:footprint2) 并生成了特征码,张三加密使用的密钥或密码就不可能是李雷和韩梅梅约定的密码,这样韩梅梅就知道这段数据被篡改过了。

    ​ 上面这段描述也存在一个问题,估计很多人都发现了。假如李雷和韩梅梅是网恋,两人从来没见过面也没约定过密码。李雷为了实现和韩梅梅加密通信。如下:

    如果使用明文交换特征码的加密密码时,就没有密码加密可言了。那网恋没有见过面的李雷和韩梅梅如何交换加密密码呢?

    双方如何协商生成密钥,但却能够不让第三方得到这个密钥,这就叫密钥交换。密钥交换需要特殊的互联网协议来支撑,最早的,也是被当作基本密钥交换算法的协议是:Diffie-Hellman协议. 密钥交换(Internet Key Exchange, IKE)

    Diffie-Hellman 交换过程:

    image-20210104140626888

    因此,有了 Diffie-Hellman密钥交换协议,李雷和韩梅梅就可以对特征码进行加密通信了。 Diffie-Hellman协议的好处也在于 李雷和韩梅梅不需要在记录密码了,只需要用一个软件,能够利用Diffie-Hellman算法,每次发送数据都重新计算一次,每次发数据都重新交换一次密钥,就算张三终于把第一次传输的密码破解出来了,第二次 密码也已经换掉了。

    密钥交换的问题解决了,密钥交换以后双方不需要事先约定密码了。但是现在问题又出现了,韩梅梅怎么知道这条信息是李雷发过来的而不是其他人发的呢?如果李雷和韩梅梅见面约定好了密码,然后韩梅梅利用已知的密码去解密,能够解密出来,这就说明是李雷发送的信息。但是现在密钥是交换生成的,在这之前没有做任何身份验证。因此,解决了密码交换的问题,身份验证的问题又没着落了。

    image-20210104142648484

    当这样的情况发生,韩梅梅是无法验证消息是否是真的是李雷发送过来的。张三说,他就是李雷,韩梅梅是无从得知的。因此,这种需要就催生了第三种加密算法的产生:非对称加密算法,也叫公钥加密算法。

    非对称加密算法特征:密钥是成对出现的。一个叫公钥(任何人都能够获取)一个叫私钥(只有私人拥有)。公钥不是独立的,公钥是从私钥中提取出来,也就是说公钥是来自于私钥的。为了保证安全性,私钥一般都是非常长。用公钥加密的,也只能用与之匹配的私钥进行解密,反之亦然。有了公钥算法以后,李雷和韩梅梅通信直接就可以使用密钥进行加密解密就可行了吗?

    image-20210104144154273

    因为密钥对是成对出现的,公钥是任何人都能获取到:

    • 当发送消息的时候用私钥加密时,因为公钥是任何人都可以获取的,其他人可通过公钥来解密并确认身份;
    • 当使用对面的公钥加密时,只有对方的私有可解密,机密性得到保证,但是无法进行身份验证。

    上面两种方式都各自只能实现不同的功能,公钥加密这种机制解决了,密钥管理的问题。

    通常情况下,公钥加密算法是绝少用来进行加密的,原因是速度太慢,密钥太长。一般来讲,公钥加密算法比对称加密算法加密数据的速度满三个数量级,一个数量级是10倍,三个数量级就是1000倍。比如,用对称加密1秒可以完成,用非对称加密得1000秒。因此公钥加密发挥的场合不是在数据机密性的保证方面,而是用作身份验证。

    image-20210104145926237

    通过上面的逻辑,身份验证和数据的完整性就得到了保证,此时使用了非对称密钥的方式来实现身份验证的功能。事实上,非对称加密的主要用途也就是身份验证。当然,这里也引出了新的问题,这一切的保证靠的就是李雷的公钥,怎么获取李雷的公钥呢?李雷和韩梅梅是网恋,两人素未谋面。双方的公钥传递是向对方获取的。韩梅梅要和李雷通信,必须要先获取李雷的公钥才能进行解密李雷发送过来的数据。

    image-20210104150916665

    假如,韩梅梅通过一个地址向李雷索要公钥,这个消息正好被张三截获,并冒名顶替说,我就是李雷,然后将张三自己的公钥传递给韩梅梅。此时的问题就是,韩梅梅怎么知道张三是不是真的李雷呢? 无从得知。

    世界上没有万无一失的安全性可言,于是就借助于第三方机构来实现,发证机构:

    image-20210104151736592

    这样显示中的例子就能很好理解。再例如:开车出门,会有交警上前查询驾驶证,然后通过他的终端来验证你驾驶证的真伪,这就是向发证机构进行求证。

    image-20210104155737129

    在这样的通信中,发证机构尤为重要。所有的安全性都是通过它来展开的。这个时候就算费事一点也是值得的。因此,李雷亲自跑到发证机构去,用U盘拷贝发证机构的公钥回来,导入到机器上去,这是最可靠的方法。发证机构也可以送上门来,将你的公钥提交给它或者上门把你的公钥拿走,做成证书,在给你送回来。这样发证机构就很忙,需要核实你的公钥、身份,还要做成公钥。还要送回来导入到机器上。于是 发证机构就开始收费了。比如你在使用的: https

    现在又有问题了,韩梅梅为了和李雷通信还得花几千块买个证书,这网恋有点贵啊。但是平时通信好像也没有用证书,比如访问某宝网站。回归上面李雷和韩梅梅通信过程,整个过程都是韩梅梅问李雷要证书,李雷并没有问韩梅梅要证书。如果只有一方有证书,身份能够得到验证, 完整性也能得到保证。但是李雷无法验证韩梅梅的身份,因为只有李雷把自己的证书传递给了韩梅梅。在互联网上一般也是采用这种方式,比如访问某宝网,只要验证某宝服务器没有问题即可,谁都可以去访问某宝。

    截至目前,李雷和韩梅梅通信具体内容都是明文传输,加密也只是正对特征码来加密的。那如何保证机密性?

    image-20210104175652659

    1. 首先李雷需要给韩梅梅发送一段信息,通过算法计算出这段信息的特征码,附加到数据的后面;
    2. 用自己的私钥给特征码加密;
    3. 再次生成一个只有自己得知的随机数将整个数据+特征码进行加密;
    4. 然后用韩梅梅的公钥在给随机数进行加密并附加到后面。

    通过上图来描述下韩梅梅接收到数据怎么解密并提取信息:

    韩梅梅拥有:自己的密钥对、李雷的公钥。

    1. 通过自己私钥解码得到随机数;
    2. 获得随机数解码得到:数据+加密的特征码;
    3. 用李雷的公钥解密 加密的特征码,得到特征码;
    4. 通过相同的算法、数据计算特征码和获得的特征码就行比较,一致则信息可信。

    从上面得知:

    整体数据是机密的,在韩梅梅通过对方的公钥解密数据的时候,对方身份也得到了保证,然后数据特征码保证了数据的完整性。

    机密性、完整性、身份验证都得到了保证。

    而这一切最开始的地方,彼此信任都是从证书开始的。证书机构的出现,使得互联网安全机密的通信成为了一种可能。而这一切综合起来就成为了互联网上的一种称呼:PKI(Public key Infrastructure)。而PKI 的核心就是证书颁发机构和它彼此之间的信任关系。

    证书颁发机构称为:CA(Certificate Authority) PKI 的核心正是CA,x509 证书包含如下:

    • 公钥及其有效期限
    • 证书的合法拥有者
    • 证书该如何被使用
    • CA的信息
    • CA签名的校验码

    互联网上著名的 TLS/SSL都是:x509的证书。

  • 相关阅读:
    .net中的委托
    GridView, DataList and ListBox 行 单击与双击事件处理
    ChineseCalendar类[转]
    数据契约(DataContract)
    XPath 语法(复习)
    正则表达式学习笔记
    瑞星笔试:现场上机做题[转]
    发送带有附件的电子邮件使用 Cdosys.dll 库
    DataContractJsonSerializer 类 操作json类型数据
    i guess a bug on Castle
  • 原文地址:https://www.cnblogs.com/hukey/p/14231592.html
Copyright © 2020-2023  润新知