常用的加密技术-对称加密和非对称加密

对称加密和非对称加密是常用的加密技术，用于保护数据的安全性。

对称加密：

对称加密使用相同的密钥进行加密和解密。这意味着发送和接收方必须共享相同的密钥，这是它的主要缺点之一。

步骤：

密钥生成： 选择一个随机密钥，通常是一串二进制数字。这个密钥将用于加密和解密数据。加密： 使用相同的密钥对明文数据进行加密，产生密文。解密： 使用相同的密钥对密文数据进行解密，还原成明文。

示例：

from cryptography.fernet import Fernet

# 生成随机密钥 key = Fernet.generate_key()

# 创建加密器 cipher_suite = Fernet(key)

# 明文 text = b"Hello, World!"

# 加密 cipher_text = cipher_suite.encrypt(text)

# 解密 plain_text = cipher_suite.decrypt(cipher_text)

非对称加密：

非对称加密使用一对密钥，公钥和私钥。公钥用于加密数据，而私钥用于解密数据。这意味着发送方可以使用接收方的公钥加密数据，但只有接收方持有私钥才能解密数据。

步骤：

密钥生成： 接收方生成一对公钥和私钥。加密： 发送方使用接收方的公钥加密数据。解密： 接收方使用私钥解密数据。

示例：

from cryptography.hazmat.primitives.asymmetric import rsa

from cryptography.hazmat.primitives import serialization

# 生成密钥对 private_key = rsa.generate_private_key( public_exponent=65537, key_size=2048 ) public_key = private_key.public_key()

# 将密钥序列化为PEM格式 private_pem = private_key.private_bytes( encoding=serialization.Encoding.PEM,

format=serialization.PrivateFormat.PKCS8, encryption_algorithm=serialization.NoEncryption() ) public_pem = public_key.public_bytes( encoding=serialization.Encoding.PEM,

format=serialization.PublicFormat.SubjectPublicKeyInfo )

# 加密和解密示例略

比较：

对称加密：速度快，适合大量数据的加密，但需要共享密钥。非对称加密：安全性高，不需要共享密钥，但速度相对较慢，适合小量数据的加密和密钥交换。

对称加密用于加密数据本身，而非对称加密用于在通信开始时安全地交换对称密钥。这种组合被称为“混合加密”。

加密通信方案

1 前言

在网络通信过程中，为保证通信安全，往往需要对通信内容进行加密，以防止敏感信息失窃或被破解。做了加密之后，通常会再使用摘要算法对特定内容进行摘要，以防被篡改。目前最流行的加密方式就是HTTPS了，双方通过信任证书，协商通信秘钥，采用都支持的加密算法和摘要算法对数据进行加密传输，保证了安全性。目前几乎所有的Web应用都是基于HTTPS实现的，解决了互联网通信过程中的安全性问题。

但是，HTTPS不是万能的。随着物联网和5G通信的发展，它的通信开销（HTTP的短连接、繁冗的Header等）不容忽视，在“大连接、低时延”的场景下并非最优的选择。

本文分享一种适用于物联网、边缘计算等“长连接”环境下的加密通信方法，在保证安全性的同时，也会大幅降低通信损耗。

背景其实是同事遇到了刁钻的客户，（物联网通信场景）非说HTTPS不安全、性能不满足要求，需要出一个方案。

2 设计思路

参考HTTPS的处理流程：

1、信任证书

客户端认证服务器服务器下发证书、认证客户端（双向认证）

2、协商并生成秘钥

在ssl握手过程中，客户端会生成一个随机数，将随机数与加密算法等信息使用证书中的公钥加密后发送给服务器，然后双方使用同样的算法各自计算生成真正的通信秘钥。

3、加密传输

后续使用这个秘钥对通信数据进行对称加密。

参考上述流程，我们需要解决问题有：

1、认证客户端身份

对于不合法的客户端，禁止其接入到核心系统。这是最基本的安全认证。

2、协商通信秘钥

每次身份验证通过之后，需要生成随机密码作为对称加密的秘钥，这样每次通信使用的都是不同的秘钥，提升通信的安全级别。

我们既要保证通信安全性，又要确保通信效率，要如何设计呢？

2.1 接口规范的设计

说明：本节内容旨在提升通信效率，跟加密通信无关

相较于HTTP协议，想要降低通信损耗，需从2个方面下手：

减少连接建立次数压缩报文头

2.1.1 减少连接次数

原因也很好理解：每次连接的建立和释放都会经过3次握手和4次挥手，频繁的创建连接会大幅降低通信性能。可以通过“长连接+心跳”来解决这个问题。

但是在“海量连接”的场景下，所有的终端都做长连接也是不现实的。这时候就需要服务端有选择地关闭一些没有业务操作的连接。例如，某些终端虽然一直连接着服务器，但是在5分钟内并没有业务消息传输，那么就可以选择关闭这种连接。

即使这样，也有可能让服务器过载。这时候就需要在服务端做“分布式+注册中心”，终端设备在访问服务器之前，先到注册中心拉取中心服务器的列表，再按照既定的路由规则进行访问。

如果还不行，那么就需要根据业务场景设置“边缘节点”，将一部分(非核心的)计算功能拿到边缘节点来做、汇总计算结果，定期上报给中心服务器。这样一来，中心服务器只需与边缘节点建立连接就可以了，不再“压力山大”。

上述手段可以结合具体场景和实际情况组合使用，实现的难易程度个人理解可以排序如下：

长连接+心跳+定期清理 < 分布式+注册中心 < 边缘计算。

2.1.2 压缩报文头

HTTP可读性强，但是其中不乏冗余信息，对业务不一定都有用，需要轻量化。

最精简的方式就是使用类似于MQTT这种“数字节”的应用层协议。我们可以自定义报文头和报文体的组织方式，充分利用二进制的每一位。这么做之后会导致传输报文的可读性很差，不能直观地了解报文中每个字节(或二进制位)的含义。也正是这种“可读性差”，不容易被抓包工具破解，变相提升了通信的安全性。

但是，如果接口协议（或规范）泄露了怎么办？这时，就需要对传输的内容进行加密。

2.2 秘钥设计

2.2.1 通信秘钥

在通信时采用加密传输，就需要相应的加密算法和加密秘钥。加密算法一般使用业界标准的AES256/512，DES3，等等。

当然也可以自定义加密算法。但是这种情况下对接比较麻烦，对于想要接入的第三方并不友好

另外一个重要的参数就是加密秘钥。对称加密时双方必须使用相同的秘钥，那么客户端与服务器之间如何协商？

我们将HTTPS的处理流程进行简化：当用户登录成功之后，在服务端直接生成通信秘钥(CommKey)，然后回传给客户端。这样，双方就不再需要各自计算秘钥了。

那么新问题来了：通信秘钥在回传的过程中如何保证安全性？当然也是加密传输。

在HTTPS中对传输的随机数采用的是非对称加密，这个算法比较复杂，而且性能很差。我们再将这个过程进行简化：对通信秘钥-CommKey 进行加密（对称加密）传输，这样既简化了处理流程，也在一定程度上提升了处理效率。

对CommKey进行加密也需要一个秘钥，这个秘钥从哪里来？

2.2.2 登录秘钥

在实际的业务场景中，用户在使用设备时都需要输入自己的用户名、密码等信息登录设备。在前文我们提到，客户端设备在接入到服务器时，服务器会对其身份进行认证。这就需要在设计接口时保留相关的认证信息，如登录用户名、登录密码、会话token等等。这里的“登录密码”-LoginKey ，就可以作为CommKey的加密秘钥。

但是，在客户端登录认证时需要传输LoginKey给服务器，也会有泄露的风险，怎么办？

2.2.3 设备秘钥

终端设备在出厂时会都会有唯一的序列号SeqNo，这个序列号是可见的。我们可以为每个设备设置唯一的秘钥-EquipmentKey ，这个秘钥随在出厂时写入设备（或双方通过某种方式约定），在业务系统中与SeqNo一一映射，而且要满足以下约束：

EquipmentKey`不参与信息传输`，只负责对登录秘钥LoginKey进行加密EquipmentKey在用户侧不可查询，对用户不可见

基于以上设计，就可以将EquipmentKey作为LoginKey的加密秘钥，这样就解决了秘钥明文传输的问题。

2.3 总结

到此，所有已知的安全隐患都解决了。重新梳理下思路，我们需要设计出“三重”秘钥：

1、设备秘钥-EquipmentKey

需要在出厂时写入设备，用于对用户登录秘钥进行对称加密。

2、登录秘钥-LoginKey

用户登录或激活设备时，随用户名一起使用；另一个功能是对通信秘钥进行加密。

3、通信秘钥-CommKey

数据传输过程中用于对称加密的秘钥，由服务端生成和生命周期维护。

后续文中如无特殊说明，则使用EquipmentKey代替设备秘钥，LoginKey代替登录秘钥，CommKey代替通信秘钥。

关于加密算法和摘要算法的协商，可以直接初始化进设备，也可以在客户端（设备）登录时指定。

2.3.1 流程说明

这里以iPhone与iCloud服务器为例，用户想从iCloud上下载通讯录时：

郑重声明：以下内容纯属“推测”，只为让大家更容易理解这种加密通信方式的使用场景和流程

用户需要使用AppleID和密码登录自己的账户，服务器对客户端进行认证。为保证登录密码（这里登录密码=LoginKey）的安全，在认证信息传输的过程中，就可以用此iPhone出厂时写入硬件的EquipmentKey对LoginKey进行加密。传输到iCloud服务器的信息至少包括：该iPhone的序列号Seq、登录用户名、对称加密后的LoginKey；iCloud服务器拿到这些信息之后，用设备的Seq找到此iPhone对应的EquipmentKey，使用EquipmentKey对LoginKey进行解密，然后验证并返回结果。如果认证成功，iCloud服务器会优先查找本地缓存中是否有`已生成且未过期`的CommKey，如果有则加密后返回；如果没有，就在本地生成指定位数的通信秘钥，并使用LoginKey进行对称加密，然后将认证结果和加密后的CommKey（也可以包括本次和后续的业务通信时使用的加密算法、摘要算法等信息）返回给此iPhone；3. iPhone收到认证结果和CommKey之后，`保存CommKey`，然后发起业务请求，如同步云端的通讯录，请求内容使用CommKey加密后传输4. iCloud服务器收到请求后使用设备Seq（或本次会话的标识，前提是在登录时生成并记录过，使用会话标识更合理一些）查询到CommKey，使用CommKey解密消息，然后解析业务请求，进行相应的业务操作。数据准备好之后，分批次不断的将该账号在云端的通讯录传输给这个iPhone，传输的内容使用CommKey加密；5. iPhone收到消息之后，使用CommKey解密、保存通讯录6. iPhone下一次发起连接之前，如果是“已登录”状态，则可以直接使用本地存储的CommKey发起业务请求；如果“登录已过期”，则需要重复步骤1进行鉴权

上述流程中我省略了摘要验证过程的描述，大家设计时不要忘记了。

2.3.2 补充

前文所述的秘钥，除设备秘钥外，都需要在服务端管理。

由于LoginKey是属于用户的“资产”，需要开放接口让用户自行修改。但是在数据传输时这个秘钥必须使用EquipmentKey加密CommKey的生命周期需要服务端来管理，如每次生成的CommKey有效期是12h。用户12h内重新登入，就可以重复使用这个密码；如果超过了12h，服务器需要通知客户端密码过期，让客户端重新登录、获取新的CommKeyEquipmentKey不能随意修改。在极端场景下(如出厂时设备中的EquipmentKey跟系统中的不一致，这种概率极小)，这时需要将设备返厂、检测、重新写入，需要设备提供相应的接口或者工具来执行这个操作。

3 后记

本文提到的加密通信方案，既可以帮你怒怼刁钻客户，又能帮你省下正版证书的钱。如果你遇到了这种客户，或者想节约成本，又或者想提升通信效率，就可以采用这个方案。

可能有人会问：用HTTP2不行吗？也是长连接，不用实现那些复杂的秘钥交换流程，而且HTTP2是标准化的协议，更方便第三方的接入。这就需要从业务场景、安全性、团队构成、研发成本等等方面综合考虑了。

个人认为本文的方案还是具备一定优势的：

通信协议更加灵活，完全可以做到比HTTP2的开销更小；安全级别更高，增加了“自定义协议”这道屏障，而且通信秘钥是可以按需随时更换

当然，你也可以根据业务发展需要让你的产品同时具备共性和个性，视场景启用相应的协议。

相关问答

wifi的安全加密协议主要有?

广泛使用的无线网络加密协议主要包括WEP加密协议和WPA加密协议两种。WEP协议也称有线等效加密协议,这种无线通信协议常常是那些急于生产销售无线设备的厂...

信息加密技术特点?

信息加密技术是对付各种安全威胁最强有力的工具,它能有效的保证数据的隐私性和和安全性。首先,对称加密体制的优点:加密速度快,保密度高。而非对称加密体制...

oppok7手机nfc功能设置非加密门禁?

打开手机设置,找到nfc功能选项。2.找到手机应用中的钱包。3.打开钱包之后,在主界面找到门钥匙功能。4.进入门钥匙功能界面,点击底部的添加。5.添加门钥匙...

什么是箍筋加密区，什么是非加密区?梁的加密区范围是多少?-...

箍筋加密区是对于抗震结构来说的。根据抗震等级的不同,箍筋加密区设置的规定也不同。一般来说,对于钢筋混凝土框架的梁的端部和每层柱子的两端都要...

加密区与非加密区怎么设置-答疑解惑-广联达服务新干线

user-scalable=no加密区与非加密区怎么设置0回答

箍筋的加密区与非加密区怎么设置?-答疑解惑-广联达服务新干线

[最佳回答]箍筋全部按间距150定义,最后另加2组箍筋。软件里只要输入了加密区后,属性下边的上加密和下加密区长度你不输入也会计算加密了,所以下边陈工的做法是...

纵向加密为什么配2台?

这个是根据地方电力调度中心相关要求来确定的,两台纵向加密的用途分别是实时纵向加密和非实时纵向加密。对应的业务就是一区业务和二区业务,这样配置两台,比...

怎么确定柱子箍筋的加密区和非加密区-懂得

首层底部箍筋加密区:大于或等于首层柱的净高/3首层上部箍筋加密区同标准层取一样。标准层箍筋加密区:[柱长边尺寸(圆柱直径),标准层柱净高/6,500mm]...

(非网络)B、信息加密C、无线网D、使用专线传输_作业帮

[最佳回答](非网络)B、信息加密C、无线网D、使用专线传输_作业帮

如何分辨箍筋加密与非加密?

现在工程施工图一般都采用“平面整体表示方法”表示结构配筋,箍筋加密与非加密无需分辨,因设计图纸中都能较清楚地注明,只是加密区的长度需要参见相关标准图集...