[TOC]
声明
** 本篇文章只是记录一些加密类型和常见算法，所用的并不是严谨的术语,而是使用日常用语以方便理解,当然都是参考各种资料后自己的理解,所以难免有理解偏差之处，欢迎指正。大神请绕路。不喜勿喷。 **
本篇文章将记录总结常见的加密类型及其算法，并最终得出常用的安全通信的方式
1 基本概念
这里只指出各个名称的关键点，具体的名词解释就不谈了……
1.1 中间人攻击
中间人攻击（Man-in-the-Middle Attack, MITM）就是通过拦截正常的网络通信数据，并进行数据篡改和嗅探，而通信的双方却毫不知情。
1.2 机密性
机密性针对的是防止对信息进行"未授权"的"读"。
- 比如，传输的信息即便被中间人窃取了，中间人拿到的信息也是对他来说不可理解的密文。
- 另外，就算是中间人花时间能解密密文，只是待他解密之后信息早就没有了当时的价值，这种情况也可以算作保证了机密性。
1.3 完整性
完整性要面对的是防止或者至少是检测出"未授权"的"写"(对数据的改变)。
比如:
- A对B发消息说下午两点见面，结果中间人C截取了消息并篡改消息为下午四点见面。这时候可以认为违背了完整性。
1.4 身份验证
简言之就是确认消息发送方的身份是否真的是他所声称的身份。
比如:
- 常常听说的钓鱼网站,例如冒充某个银行的页面等你输入账户密码等，这种情况就算是违背了身份验证。
1.5 抗抵赖性
本人认为抗抵赖性可以归结到身份验证中去。当然，只是个人观点了。
1.6 怎么样才算安全的通信？？？
一般而言，同时满足了 机密性 (信息不被泄露,或泄露后对别人来说并没实际价值)、 完整性 (信息不被非法篡改或被篡改后可以检测到)和 身份验证 (和自己通信的人确实就是我认为和我正在通信的人)。就可以认为是安全通信了。
此处将抗抵赖性归结到身份验证中。
下面就来看看常见的一些加密类型满足哪些安全要素。
2 单向加密
2.1 特征
- 输入一致 ==> 特征码一致
- 特征码一致 ==> 输入不一定一致(碰撞)
- 雪崩效应
- 特征码定长
- 不可逆(无法根据特征码还原数据)
2.2 常见算法
- MD5(Message Digest algorithm 5):消息摘要算法
- SHA(Secure Hash Algorithm):安全散列算法
- HMAC(Hash Message Authentication Code):散列消息鉴别码
- CRC(Cyclical Redundancy Check):循环冗余码校验
2.3 满足哪些安全特性?
| 机密性 | 完整性 | 身份验证 |
|---|---|---|
| 不满足 | 满足(特征码不一致可以检测出数据被篡改过) | 不满足 |
3 对称加密
双向加密是加密算法中最常用的，它将我们可以直接理解的明文数据加密为我们不可直接理解的密文数据，然后，在需要的时候，可以使用一定的算法将这些加密以后的密文解密为原来可以理解的明文。
3.1 特征
- 优点
- 加/解密速度快
- 密钥管理简单
- 适宜一对一的信息加密传输
- 缺点
- 加密算法简单
- 密钥长度有限
- 加密强度不高
- 密钥分发困难
- 不适宜一对多的加密信息传输
3.2 常见算法
- DES(Data Encryption Standard):数据加密标准
- AES(Advanced Encryption Standard):高级加密标准
3.3 满足哪些安全特性?
- 机密性:满足
- 完整性:不满足
- 对称密钥可能泄露或被破解
- 无法保证解密后的数据没被修改过
- 身份验证:不满足
- 对称密钥可能泄露或被破解
- 无法保证能正常解密的数据不是中间人发的
4 IKE
Internet Key Exchange(IKE) 互联网秘钥交换。此处简单提一下Diffie-Hellman-key-exchange。
http,ftp,smtp,telnet这些常见的协议本身并不直接支持加密传输数据。
4.1 秘钥交换过程
此处假设A和B双方要生成秘钥，秘钥交换的大致过程如下:
双方协商好一个大素数p和一个生成数g,p和g是真正在互联网上传输的。双方协商好p和g之后计算如下:
1) A生成一个随机数x
B生成一个随机数y
2) A计算g^x%p 记为M,将M传输给B
B计算g^y%p 记为N,将N传输给A
3) A计算N^x==(g^y%p)^x==g^xy%p 记为C1
B计算M^y==(g^x%p)^y==g^xy%p 记为C2
4) C1和C2就是秘钥，并且C1==C2
4.2 特征
- 在整个过程中,只有p、g、M、N四个数字在互联网上传输。
- 真正的秘钥是双方计算出来的，并不需要在互联网上直接传输。
- 只凭借这四个数字来推算出真正的秘钥几乎是不可能的。
- 可以方便的更换秘钥
5 非对称加密算法
5.1 特征
- 非对称加密,机密解密使用不同的秘钥
- 秘钥对儿
- 私钥(s):很长的一段密码,比如1024位、2048位或者更长
- 公钥(p):利用一定的机制从公钥中提取
- 用自己的私钥加密的密文只能用与之配对的公钥解密(签名、身份验证)
- 用对方的公钥加密的密文只能用与之配对的私钥解密(机密性)
5.2 身份认证
- 公钥加密解密代价太高,所有很少直接用来解密传输数据的机密性
- 主要用途就是身份认证
此处以A向B发送数据为例:
此处暂且认为公钥私钥已经拿到并且可靠
1) A用自己的私钥加密明文数据的特征码,并传输消息体(明文数据+私钥加密后的特征码)
2) B用A的公钥解密特征码
解密出错===>无法用A的公钥解密===>消息不是由A发送的
解密成功
B重新计算特征码并和解密之后的特征码比较
一致===>则认为数据没被篡改并且是由A发送的
不一致===>则认为数据是由A发送的,但是传输的明文数据被篡改过了
整个过程中：
- 中间人若是只修改明文数据===>B计算的两次特征码不一致
- 中间人若是修改了特征码===>B无法用A的公钥解密
5.3 常见算法
- RSA(设计者的名字命名-Ron Rivest, AdiShamir、Leonard Adleman)
- DSA(Digital Signature Algorithm):数字签名
5.4 满足哪些安全特性?
- 机密性:不满足
- 数据是明文的
- 完整性:满足
- 信息被修改后无法通过对应的公钥或私钥解密
- 身份验证:满足
- 私钥加密的数据只能用对应的公钥解密
5.5 引入的问题
- 公钥、私钥去哪里获取呢？
- 怎么确定公钥、私钥的可靠性呢？
通信双方找一个双方都信可的机构，作为公正方。
这就类似于现实生活中的公安局颁发身份证，你认可公安局就得认可公安局发的身份证了。
这里的公正方就是CA(Certification Authority)了。请看下文:
6 CA(Certification Authority)
6.1 简单介绍
上面说了既然CA是通信双方都信任的公正机构，那么找CA验证和自己通信的对方的证书的真伪就可以了。
CA将用户的基本信息和用户公钥生成特征码并用CA自己的私钥加密作为用户的证书。另一个用户想要辨别该证书真伪，只需用CA的公钥解密该证书，并对比特征码即可。
以下是来自百度百科对CA的描述:
- CA 也拥有一个证书（内含公钥和私钥）。任何都可以用户通过验证 CA 的签字从而信任 CA ，任何人都可以得到 CA 的证书（含公钥），用以验证它所签发的证书。
- 如果用户想得到一份属于自己的证书，他应先向 CA 提出申请。在 CA 审核通过后，为申请者分配一个公钥，并且 CA 将该公钥与申请者的身份信息绑在一起，并为之签字后，便形成证书发给申请者。
- 如果一个用户想鉴别另一个证书的真伪，可以用 CA 的公钥对那个证书上的签字进行验证，一旦验证通过，该证书就被认为是有效的。证书实际是由证书签证机关（CA）签发的对用户的公钥的认证。
- 证书的内容包括：电子签证机关的信息、公钥用户信息、公钥、权威机构的签字和有效期等等。目前，证书的格式和验证方法普遍遵循X.509 国际标准。
6.2 PKI
PKI(Public Key Infrastructure)----公钥基础设施，其核心就是CA了。关于具体的严谨的术语定义请自行科普。
6.3 引入的问题
难题一：
- 去哪里获得CA自己的证书呢？
- 怎么确保自己获得的就是真正的CA的证书呢？
- 怎么确保CA不是冒名顶替的？
感觉又跳坑里了……
- 一般情况获得证书都是通过网络传输的
其实,到这一步就真的没什么能保证的了……
互联网这么大,计算机这么多,谁知道和你网上谈话的是人还是计算机呢？
不扯了……
如果你非要保证万无一失,那么CA当然也提供付费服务来尽力为你保证安全了：
- CA上门来把你的公钥通过安全的存储介质复制到CA自己的服务器上……
- 做成证书用安全的存储介质给你复制到你自己的服务器上……
- ……
难题二:
自己辛辛苦苦搞到手的私钥丢失怎么办，被人窃取怎么办？
- 可以借助于秘钥管理工具
- 但是秘钥管理工具被攻击了呢？
- 一个标准的CA应该有CRL(证书吊销列表)
………………………………
………………………………
这样一层一层想下去……会疯掉的………………
总之，还是有风险的……目前大概没有什么可以万无一失的策略吧……
7 如何安全通信呢？
以上的加密类型并没有一种同时满足了机密性、完整性和身份验证这三个安全特征的？
这么多加密算法、加密类型。怎么确保通信是“安全的”的呢？
以下所说都是基于CA以及CA自己的证书是可信的基础之上的。还是以A和B通信为例:
7.1 方式一
1) A和B拿到对方的公钥
A的公钥、私钥分别记为:pa,sa
B的公钥、私钥分别记为:pb,sb
2) A和B通过IKE协议生成一个对称秘钥，记为m
3) A===>B发送信息
A将消息体用2中生成的对称秘钥m加密
消息体包括:
明文数据(plantext)
sa加密的plantext的特征码
4) B解密数据
B用m解密整个消息体(m是通过IKE生成的,可以认为只有AB双方知晓)
解密出错===>消息不可信
正常解密===>继续下面步骤
B用pa解密用sa加密的特征码
解密出错===>身份验证失败
正常解密===>继续下面步骤
B重新生成特征码并和解密后的特征码对比
对比一致===>消息可靠(机密性、完整性、身份验证都保证了)
不一致=====>消息发生了变化
虽然同时满足了机密性、完整性和身份验证三个安全因素。
但这个过程有点复杂了，还要借助于IKE协议，非对称加密的代价也是很大。
7.2 方式二
此处还是以A向B发送信息为例:
1) A和B拿到对方的公钥
A的公钥、私钥分别记为:pa,sa
B的公钥、私钥分别记为:pb,sb
2) A生成一个随机串儿(m)作为对称密钥来机密明文数据
消息体包括:
用m加密的明文消息
用sa加密的特征码
用pb加密的m
3) B解密消息
用sb解密得到对称密钥m
用m解密密文得到明文
重新计算特征码并与用pa解密得到的特征码对比
这个过程并不依赖于IKE协议生成对称密钥。
真正的对称密钥是加密后附加在消息体中的。
