通信链路安全

加解密相关常见概念

密钥

密钥与算法一起使用，密钥+算法+明文=密文

密钥根据算法的不同，一般会是一个（对称加密）或者一对（非对称加密）

公私钥

公私钥一直是一个比较容易混淆的概念，这里仔细说下

1. 公私钥首先存在于非对称加密的场景
2. 密钥本身并没有所谓公私的概念，所谓公私只取决于你对他的使用，比如，密钥A和B是一对密钥，A和B都能对彼此加密的数据进行解密，但是A和B之中被发放出去的就是公钥，自己保管的就是私钥，公钥可以发放给很多人，所以一般说，私钥才是这对密钥的主人
3. 虽然RSA的公钥加密比私钥解密要快，说明公私钥还是有区别的，但是一般来说公私钥的本质区别还是由是否分发出去来区分
4. 具体的后面会有例子详细讲解

算法

算法一般分为2种常见类型：签名、加解密

签名

签名和摘要一般是一起的，所以签名算法一般都是摘要类算法，特点是不可逆、速度快，常见的有：

1. SM3（国密算法）
2. MD5
3. HASH
4. SHA散列函数家族

签名算法的攻击

签名算法一般的攻击方式是彩虹表，因为摘要一定是损失信息的，所以基本都是通过彩虹表碰撞来得到明文

加解密

加解密算法的特点就是可逆（通过密钥解密），速度慢，常见的有：

1. SM2，SM4（国密算法）
2. AES、DES
3. RSA

加解密算法的攻击

加解密算法的攻击一般通过以下途径：

1. 猜测算法
2. 拿到密文和明文
3. 通过一些方式，使用密文+明文+猜测的算法，去计算或者碰撞出密钥
4. 比如RSA，在知道明文密文的情况下，通过公钥，就可以通过算法的原理来反向生成私钥，只不过RSA的公私钥是通过大质数拆解得到的，所以这个过程会非常久，这也是为什么随着算力提升，RSA密钥的长度也一直在变长的原因

防御加解密攻击

所以防止加解密攻击，主要就是保护密钥+保护算法，如果被攻击者既知道了部分密钥又知道了算法，那么在专业的人眼中就十分容易破解

举个例子就是MD5，如果不加盐并且明文较短的MD5百度彩虹表都可以直接逆向得到明文，比如经典的e10adc3949ba59abbe56e057f20f883e

签名与加解密

大部分人以及文章其实一直混淆了签名和加解密的概念，包括他们的目的和用途，这里明确下相关的概念，以便大家在实际情况中知道什么场景该使用什么途径和手段

在互联网安全上，最典型的攻击就是中间人类型的攻击，签名和加解密都可以进行一定防范

签名

目的

签名的目的，是防止信息在传输链路上被篡改，以及保证来源的可靠性，虽然加密也可以防止信息被篡改，但是两者目的以及效率是不同的

这也就是很多人一直没搞清楚签名和加密的原因，加密当然也可以达到一样的效果，但是就像慢跑也可以锻炼，跑马拉松也可以锻炼，在签名就可以解决的场景使用效率更低的加解密是没有必要的

主要的方式就是，在传输信息时，除了信息本体之外，还额外传输一段本体的摘要，也就是最终传输的数据包括明文+明文的摘要

方法以及流程

一般有2种形式，对称式和非对称式

对称式（MD5，HASH，AES）描述：

1. 发送方使用摘要算法或者使用对称密钥加解密，对报文进行摘要
2. 将报文本体与摘要一起发送
3. 接收方在收到报文时，使用相同的摘要算法或者使用对称密钥加解密，对报文进行摘要，将自己生成的摘要和接收到的摘要进行对比，相同就可以确定报文没有被修改

非对称式（RSA）描述：

1. 发送方使用私钥对报文进行加密，得到摘要
2. 将报文和摘要一起发送
3. 接收方在收到报文时，将密文使用发送方的公钥解密，可以成功解密得到有效报文的，就确认报文没有被修改并且发送者是发送方本人

签名保障安全性高的要点就是：

1. 防止算法泄露，如果你只是简单的使用不加盐md5，因为md5的结果串十分明显，所以很容易被猜测到，这样别人在修改报文后直接md5生成新的摘要，就可以直接破解
2. 对“密钥”的保护。如果是MD5，双方需要对加的盐进行保密，如果是加解密算法，则需要对密钥保密

加解密

目的

加解密除了包含了签名的效果之外，多出的功能是防止内容被窃听

举个例子，如果一个医院要向国家上报病人得病情况的信息，消息体内容是（姓名、年龄、得的是什么病），这类数据泄露并被人获取到卖给灰产，你就会收到一堆莆田医院的电话叫你去送钱了

这种窃听可能发生在数据传输的任何环节，比如写字楼的交换机被人黑了，或者是DNS被篡改了，如果你的信息够值钱，甚至他可能会攻击任意一个数据交换中心来窃取这个内容

方法以及流程

这里对称以及非对称的处理一样

1. 发送方对整段报文使用密钥以及算法，进行加密，发送密文
2. 接收方对整段密文使用密钥以及算法，进行解密，拿到明文

签名与加解密工业实践方案

一般银行里对外的接口，或者银行内部跨系统之间，以及银行外部系统和银行核心系统之间，一般是使用2对公私钥来保证通信链路的安全的，下面描述一下定义和流程

如果ewtprod和study要进行安全通信，那么需要2对非对称密钥E和S

1. 发送方ewtprod，使用E的私钥进行签名后，得到报文和摘要，再对报文和摘要，使用S的公钥进行加密，得到整段密文
2. 将整段密文发送到接收方
3. 接收方study对密文使用S的私钥解密后，得到报文和摘要，使用E的公钥对摘要解密，对摘要解密成功即确认报文来源是E
4. study使用同样的方式，即使用S的私钥进行签名后，得到报文和摘要，再对报文和摘要，使用E的公钥进行加密，得到整段密文并返回

Https

结合前面的概念，我们回顾下Https的原理，Https的步骤如下：

1. 请求方获取服务方的公钥，选取一个对称算法并生成一个对称密钥，将算法以及密钥通过服务方的公钥加密，发送给服务方
2. 服务方通过私钥解密，获得对称算法以及对称密钥，使用对称算法以及对称密钥对返回进行加密，返回成功
3. 请求方使用对称算法以及对称密钥解密，确认对称信道建立，双方后续使用对称算法以及对称密钥进行通信

Https最容易被攻击的，反而是公钥也就是所谓证书的可靠性（证书中包括公钥），所以才有了CA这种证书颁发机构，CA根证书有很多是直接安装在计算机系统中的，在建立https之前，会先通过预先安装的CA根证书和根证书颁发机构建立https连接，来从根证书颁发机构来获取实际请求服务器的证书

防注入

SQL注入

这个大家都比较清楚，就是通过sql里包含where 1=1等条件绕过登录，或者通过注入恶意sql攻击数据库

XSS攻击

Xss攻击目前我们都是没有防范的，但是如果找绿盟来做等保认证，又会是一定要求整改的

Xss主要是跨域脚本攻击，通过提交构造好的脚本内容，来攻击网站，攻击方式大致如下：

1. 攻击者提交一段js脚本到服务器，服务器未做校验，保存了下来
2. 另外的用户访问到该数据时，服务器返回了这段js脚本，浏览器将其加载到网页上，浏览器会渲染并执行这段js
3. 如果提交的恶意js为无限弹窗，则会导致浏览器崩溃，网站完全无法打开
4. 如果提交的恶意js为跨域表单提交攻击，则可能会导致用户财产损失

这类攻击高发区就是用户可以提交内容，并且提交的内容会给其他用户展示的区域，典型的如评论等功能

比如我在评论区回复一段js脚本，脚本内容就是使用form表单向银行提交一个转账请求，此时如果用户刚好打开了那个银行的网站并处于登录态，因为浏览器的特性，请求时会自动带上相关的cookie直接去请求，用户的钱就被转走了

现在大部分服务端都有所防范，会拒绝跨域的请求

防范：

1. 对于输入的内容，要通过正则等方式，对常见js脚本内容进行过滤，比如过滤<>!sumit alert . 等字符和内容
2. 对于被请求时，要开启跨域检查，对于跨域的请求进行拦截
3. 不要使用session机制来确认用户的身份，而是使用token

商用密码最高安全级别

目前商用密码最高安全级别的实现，就是支付密码的实现，由国密局制定规范，用于支票的兑现

主要的原理就是使用特定的算法，来进行密码的计算以及核验，首先具有支付密码设备经营资格的企业，可以定期从国密局直接购买一定数量的芯片（芯片有两类，一个核验芯片一个密码器芯片），然后将大量芯片集成到核验机上，将核验机卖给银行

客户开通支票业务时，银行会使用一个密码器（用户端，和令牌差不多），将密码器与核验机连接，核验机进行发行操作，核验机某个芯片上会生成一对密钥写入密码器的芯片中，发行成功

客户在使用支票时，除了填写支票以及签字盖章之外，还需要将支票上的六要素：包括金额，开户行号，日期，支票号，等信息输入密码器，计算出密码后，填写到支票上的密码那一栏

支票拿到银行兑换时，除了需要核验签字和章之外，最主要的会输入六要素到核验机，去核验支付密码的正确性，支付密码正确的支票才可以兑现

这种密码交互逻辑，也就是大多数手机令牌或者各种安全令牌的交互逻辑