Web信息传递的安全性
web信息的传递建立在tcp/ip协议基础之上，然而tcp/ip只是保证了信息的可送达，却并未保证信息的安全性。在现今的web系统中，信息安全是必须要考虑的重要问题，处理的稍有不慎就会在某个时刻酿成巨大的损失。本文为各位总结了现今web信息安全方面的主要技术，以及其解决的问题，为大家在web信息安全这块提供一个整体的认识。
web信息传递模型
上图展示的是建立tcp/ip基础之上的信息传递模型，从中我们可以发现数据的安全问题主要发生在传递的过程中。个人对于web数据正确及安全传输给出3大要求，这3大要求本身是在传输过程中可能产生问题的三个方面的总结。三大要求如下：
- 信息安全
- 信息完整
- 对象正确
信息安全
信息安全这一要求主要解决的是在数据传递时，如果我们使用明文则数据会被他人窃取的情况。对于一般性的数据，这无关紧要，但是如果是私密性的数据，比如用户的登录口令，银行卡账号，自己的私人信息等等，这则是一个很严重的问题。针对这一问题，主要的解决方案就是加密，现在主流使用的加密分为两类，对称加密和非对称加密。二者的区别，主要在于加密和解密的秘钥是否相同，对称加密使用的加解密秘钥相同，而非对称加密则使用不同的加解密秘钥。
对称加密
对称加密从早期的DES、3DES到目前的AES目前已经有了较高的安全强度。DES和3DES基于Feistel网络实现，而AES则使用的是效率和安全更高的SPN结构。目前web系统主要使用AES算法，DES和3DES除了较旧的系统在使用，新的web系统一般不建议使用。关于三种算法的具体实现思路，一般的开发者不必深究，只要做到会用并知道在什么时候使用即可。
DES和3DES的实现算法
DES和3DES的实现都是基于Feistel网络，在Feistel网络中基础单元称为“轮”，通常des加密的feistel网路有16轮，（见下图）。
从图中可以看出feistel网络处理的单元是64位明文，des秘钥要求长度也为64位（实际上只有56位，另外8位被用于校验）。Feistel对输入的64位明文划分为左侧32位和右侧32位进行处理，其中右侧32位不进行任何操作直接输出为密文，而左侧32位则使用以右侧32位和秘钥计算生成的32位子秘钥进行异或（XOR）操作生成密文的左侧32位。
上图中所绘制属于des的feistel网络的基础单元，des算法通常使用16个这样的单元相互连接，加密出最终的密文。在feistel单元连接的时候，上一个单元计算出的64位密文中的右侧32位将作为下个feistel单元的左侧32位，进行左右交叉。
在des的feistel网络的加密中还有一点需要注意的就是密钥的调度，秘钥的调度本质是生成16个轮所需要的16个子秘钥。秘钥调度首先从输入的64位秘钥中使用选择置换1，选出56位秘钥，然后将56位秘钥分成两个28位的秘钥，每个28位秘钥在每次的轮计算中被循环左移1位或2位，循环之后的28位秘钥使用选择置换2生成24位的秘钥，在将两个24位秘钥组成一个48位秘钥形成子秘钥，这样迭代16次之后生成16个48位子秘钥，供后续的16轮feistel网络使用。（具体的轮函数可以参考维基百科)
对于3des简单点说就是讲des算法执行3遍，但是需要注意的是为了考虑向下的兼容性问题3des的des组成为[des加密=>des解密=>des加密]。
AES实现算法
AES使用的是SPN网络实现的，处理的数据为128位明文数据，秘钥长度可以为128位、192位、256位，基础的计算单元分为4个步骤分别是SubBytes、ShiftRow、MixColumns、AddRoundKey。加密的过程为上述4个步骤的顺序执行，而解密的过程则为4个步骤的逆序执行。每个步骤所做的事情为（将16个字节的数据想象成4*4的矩阵可以方便的理解）：
- SubBytes，利用一张替换表处理每个输入的字节（本质上是一种映射）。
- ShiftRow，对替换后的数据进行除第一行外的每行循环左移处理，依次移动1、2、3字节。
- MixColumns， 简单点就是将其与固定矩阵相乘。
- AddRoundKeys，将上一步骤的结果与回合秘钥进行异或计算。 上述基础计算单元，在AES算法中一般会迭代执行14-16次
对于DES算法，具体的细节可以参考维基百科，有兴趣的朋友可以深入的去了解并实现，个人建议在正常的使用中大致了解其过程即可。
比较AES和DES算法，可以发现AES每一轮计算所有的输入数据都参与加密了，而DES只有一半的数据参与。另外，AES算法可以进行并行计算，执行效率会更高。现今对称加密一般都使用AES，不推荐使用DES或3DES。
对称加密的模式
对称加密的模式，描述的是将任意长度的明文以加密算出处理数据长度进行分割，迭代执行，进行明文加密的各种方法。出现这一问题主要是因为对称加密处理的都是固定长度的输入单元，而明文则是任意长度的。目前主要有以下5种模式：
- ECB模式：Electronic CodeBook mode（电子密码本模式）
- CBC模式：Cipher Block Chaining mode（密码分组链接模式）
- CFB模式：Cipher FeedBack mode（密文反馈模式）
- OFB模式：Output FeedBack mode（输出反馈模式）
- CTR模式：CounTer mode（计数器模式）
上述5个模式的流程分别如下图所示:
对于对称加密的各个模式，主要区别表现为：CBC以上一次密文数据和本次明文数据异或的值作为加密算法的输入，CFB以上一次密文数据作为加密算法的输入接着在和本次明文数据异或，OFB以上次加密算法的输出作为本次加密算法的输入接着在和明文数据异或生成密文数据，CTR模式则每次生成不同的计数器作为加密算法的输入接着在和明文数据异或生成密文数据。
在对称加密算法的使用中，不推荐使用ECB，CBC模式。
对于对称加密，虽然加密了明文数据，但是由于其加解密的秘钥都相同，存在着秘钥传输的问题。
非对称加密
非对称加密RSA核心的内容是两个取余运算，但是这取余的背后包含着大量的数学上的证明保证其正确性的，对于相关的证明这里做多余讲述，感兴趣的朋友可以深入了解这块。
密文 = 明文^E mod N 明文 = 密文^D mod N 公钥 {E, N}， 密钥{D, N}
对于非对称加密大家一般了解其整个使用流程是如何即可。
使用非对称加密一般需要先生成一对公钥和私钥，公钥提供给需要向你发送消息的人，私钥则自己保存。他人使用公钥加密需要发送的消息，收到消息之后自己则使用私钥解密获取原文。整体流程为消息 => 公钥加密 => 密文 => 传输 => 接受 => 私钥解密 => 明文。
非对称加密解决了对称加密的秘钥传输的问题，但是中间人攻击的问题却并没有解决。
信息完整
信息完整主要指，虽然在消息进行加密之后，但是可能存在部分数据被修改或者丢失的情况。这时候就需要一种方式保证消息数据本身在传输的过程中没有发生改动，目前业界使用单向散列函数的方式解决这一问题。
单向散列函数能够将输入的任意数据经过计算之后输出固定长度的二进制数据（散列值），且输入数据有任何不同输入的结果也会不同。如果要是发生了对于不同输入数据生成了相同结果的情况，则称之为（碰撞）。对于碰撞的问题，感兴趣的朋友可以深入这块。
常见的单向散列函数有MD5、SHA-1、SHA-256、SHA-348、SHA-512。每个具体的散列函数是如何实现的以及碰撞相关的问题，由于内容太多，这里不做介绍。
对象正确
对象正确主要指的是在消息来自于正确的对象发送，而不是他人伪装发送过来的。为了解决这一问题有两种方案可供选择，分别是消息认证码和数字签名技术。
-
消息认证码
消息认证码指通过将任意长度的消息和接受者与发送者共享的秘钥计算得出固定长度的数据，简单的说就是一种与秘钥相关联的单向散列函数。它要求接受者和发送者之间必须拥有共享的秘钥。一般实现消息认证码有基于单向散列函数和基于对称加密两大方法。消息验证码可以解决数据的完整性和发送对象认证的问题，但是其本身也存在秘钥配送和消息否认的问题。消息否认是指对于第三者而言，无法确定消息是由共享秘钥二者中的哪个发送。也就是说消息认证码仅限于在接受者和发送者之间的认证。
-
数字签名
数字签名类似于现实世界中个人签名或公章，对消息进行签名。它利用公钥密码的思路，实现了对消息发送者的唯一性确认。数字签名一般使用RSA算法实现，可以对消息的整体记性签名也可以对消息的散列值进行签名。虽然对散列值进行签名实现麻烦，但是实际应用中一般都对消息的散列值进行签名。可以发现数字签名有一个基础条件，即数字签名的公钥必须是正真的发送者的。对于数字签名，存在中间人攻击和公钥伪造的问题。
数字签名和公钥密码很相似，主要区别在于数字签名的加密使用的公钥密码中的私钥，签名的解密则使用的是公钥密码中的公钥。
对于数字签名，我们可以发现和公钥加密同样的问题，就是中间人攻击，即我们如何能保证公钥是正确。这一问题，最终通过证书的方式解决，也就是说第三方公信机构存储所有由它保证是安全并且正确的证书，当我们需要获取公钥的时候，则从第三方公信机构获取。同时第三方公信机构对自身颁发的证书必须要进行数字签名以保证证书确实由它颁发。
小结
上述从信息安全、信息完整和对象正确三个方面介绍了目前加密和解密的常用方法以及该方法的流程。在现实的情景中，一般是多种技术的组合以保证最终消息的成功传递。个人认为较为完善的信息加密应是建立在数字签名基础上的，结合对称加密技术的方法，因为此方法不仅保证了效率同时也兼顾了安全性。
847
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
