在TCP/IP设计之初,并没有考虑安全性问题。随着互联网的普及,人们发现,在这种开放式的传输体系之上,网络安全问题层出不穷。例如:有两台主机A、B,A、B之间从来没有通信过,其可能面临的安全问题有:
1、TCP/IP协议数据传输采用的是明文传输(如:ftp,smtp,http,telnet等),因此数据的机密性无法得到保证;
2、在两台主机数据传输过程当中,传输的数据可能会出现被篡改的情况,数据的完整性无法得到保障;因此,当发现接收到的数据与对方发送过来的数据不一致时,应该拒绝使用这个数据;
3、对于两台此前从来没有通信过的主机,需要有一种手段保证要通信的那台主机的身份与其声称的身份想匹配,其身份应该得到确认,即需要进行身份验证,避免第三方主机伪造身份来建立通信。
因此,以下从这三个角度进行分析如何实现TCP/IP数据传输的安全性。
一、TCP/IP中保证数据安全性的分析
1、机密性
数据的机密性即需保证两台主机之间的数据通信不能被第三方查看,而此前TCP/IP协议的数据都是明文传输的。因此,数据的机密性无法得到保证,此时引入加密机制即可保证数据的机密性。如:当A主机发送数据到B主机时,发送的数据需要通过某种转换规则转换为一串无序字符串,而当B主机接受到数据时,通过对应的转换规则,将无序字符串还原成数据,这个过程就叫做加密传输,转换规则即为密钥,生成转换规则的方法称为加密算法。
简要示例如下:
加密:plaintext(明文)-->为了不让第三方获取这个信息,需要加密(转换规则)-->ciphertext(密文)
解密:ciphertext(密文)-->转换规则-->palintext(明文)
上述状况会出现一个问题,就是转换规则可能被窃取。而此时保证数据安全性的是密钥,而不是算法本身。因此,设计一个
2、数据完整性:
若A-->B采用明文加密,数据易被篡改。如何保证数据不被篡改掉?
A:plaintext:footprint(特征码)-->B
Eve:plaintext2:footprint(被篡改)-->B
B:plaintext:(footprint)(特征码加密)-->B
如上述过程,为避免数据被篡改,可将特征码加密附加在数据尾部,当客户端接受数据时,用相同的算法将数据单向加密一次形成特征码,比较两个特征码是否相同,若相同,即数据未被篡改,若不同,将数据丢弃。
但其中有一个问题,若A,B之间从来没有通信过,如何约定加密通信的密钥呢?此时就需要协商生成密钥:密钥交换(Internet Key Exchange,IKE,双方协商如何生成密钥,但是不让第三方得到密钥,需要特殊的互联网协议支持),最早也是今天被当做基本密钥交换算法(机制)的协议:Diffie-Hellman协议
使用Diffie-Hellman协议协商过程(算法原理):
A-->B协商生成一个大素数(只能被1和本身整除的数)p和一个生成数g,随后A在本机内部生成一个随机数x,B在本机内部生成一个随机数y,(A不知道B的y,B不知道A的x)而后A将计算结果g^x%p发送给B,B将计算结果g^y%p发送给A。在互联网上只能看到4个数字,分别为:p,g,g^x%p,g^y%p(因为离散对数的问题,很难倒推出x,y的值)。在A计算密钥:(g^y%p)^x=g^(xy)%p,在B计算密钥:(g^x%p)^y=g^(xy)%p。故而每一次数据通信,都可以通过响应的软件改变一次密钥,提高安全性。
简述:
A-->B
p,g(大素数,生成数)
A:x(随机数)
B:y(随机数)
A:g^x%p-->B
B:g^y%p-->A
g,p,g^x%p,g^y%p
密钥交换算法举例:
g=2
p=7
x=2
y=3
3、身份认证
发送方用自己的私钥加密数据,可用于保证身份认证;
二、几类常用的加密算法
1、对称加密算法
分加密算法和解密算法,加密和解密使用同一个密钥。对称加密的好处在于算法的计算速度非常快,但其安全性几乎完全依赖于密钥本身(因为很多算法是公开的)。当通信对象很多时,无法有效的对密钥进行管理(每一对通信对象都有自己独有的密钥)。因此对称加密算法在一定程度上解决了数据机密性的问题,但没有办法帮用户解决密钥管理问题。
2、单向加密算法
单向加密算法旨在提取数据的特征码,为保证数据的完整性,其特点如下:
1、输入一样,输出必然相同;
2、雪崩效应:输入的微小改变,将会引起结果的巨大改变;
3、定长输出:无论原始数据多大,结果大小(长度)相同;
4、不可逆:无法根据特征码还原数据。
3、公钥加密算法:非对称加密算法(主要用于身份验证)
密钥对(公钥是通过某种机制从私钥中产生的,用公钥加密的数据,只能通过与之配对的私钥解密):
公钥:p
私钥:s
发送方用自己的私钥加密数据,可用于保证身份认证;
发送方用对方的公钥加密,可用于保证数据的机密性。
公钥算法很少用来加密数据:(因为密钥太长,故而)速度太慢(一般来讲,公钥加密算法比对称加密算法慢3个数量级(1个数量级是10倍))
小结:(举例)
上图中 ,A-->B使用A的私钥加密能够保证数据的完整性和实现身份验证,但不能保证数据的机密性。
A,B能够实现通信的前提是A能够将公钥发送给B,那么A如何把公钥发送给B呢?而B又如何确定接受的公钥是A发送过来的呢?需要借助于第三方可信机构实现。A生成一对密钥(s/p),为了保证公钥传递给B的时候,B能够认可,需要把公钥传递给第三方机构,由第三方机构为其做公证。
第三方机构制作一个数字证书,证书中包含A的用户名,地址,公钥,发证机构的戳(前面所述信息的特征码)等信息。而发证机关自己也有自己的证书,将自己的证书做成了密钥对,它先给自己发一个证,发证机关先去计算证书的特征码,并将特征码用自己的私钥加密附加在证书后面吗,故而只有拿到机构的公钥才能得到数据信息。哪个附加在证书后的特征码就叫做数字签名(戳)。
同样的道理,B申请了自己的证书,B为了与A进行通信,B给A发送了请求,随后A将自己的证书发送给了B。B拿到证书后就得到了A的公钥了,B可通过发证机构的公钥(通过发证机构的证书可得到发证机构的公钥)对证书认证其合法性(数据完整性认证)。
为保证数据的机密性,可通过对称加密实现,A生成一段随机数作为对称密钥,将数据和特征码加密,再使用B的公钥将对称密钥加密,这要对称密钥就只能通过B的私钥解密获得了。
而这一切的基础都是基于对对方证书的信任。
私钥可能会丢失,私钥丢失后,势必会导致证书的失效,任何基于此证书与此用户建立的通信都应该宣布失效,如何在互联网上实现这一问题呢?
可通过CA实现,一个完整的CA应该维护一个证书吊销列表(CRL:保存此前曾发出的未过期但已经被撤销的证书)
原文地址:https://www.cnblogs.com/long-cnblogs/p/10439226.html