加密通信方案

前言

在网络通信过程中,为保证通信安全,往往需要对通信内容进行加密,以防止敏感信息失窃或被破解。做了加密之后,通常会再使用摘要算法对特定内容进行摘要,以防被篡改。目前最流行的加密方式就是HTTPS了,双方通过信任证书,协商通信秘钥,采用都支持的加密算法和摘要算法对数据进行加密传输,保证了安全性。目前几乎所有的Web应用都是基于HTTPS实现的,解决了互联网通信过程中的安全性问题。
但是,HTTPS不是万能的。随着物联网通信和5G的发展,它的通信开销(HTTP的短连接、繁冗的Header等)不容忽视,在“大连接、低时延”的场景下并非最优的选择。
本文分享一个适用于物联网、边缘计算等“长连接”环境下的加密通信方法,在保证安全性的同时,也会大幅降低通信损耗。

2020年5月6日
背景其实是上周同事遇到了这种客户,(物联网通信场景)非说HTTPS不安全、性能不满足要求,需要出一个方案

设计思路

参考HTTPS的处理流程:

  • 信任证书
    • 客户端认证服务器
    • 服务器下发证书,双向认证
  • 协商并生成秘钥
    • 在ssl握手过程中,客户端会生成一个随机数,将随机数与加密算法等信息使用证书中的公钥加密后发送给服务器,然后双方使用同样的算法各自计算生成真正的通信秘钥
  • 加密传输
    • 后续使用这个秘钥对通信数据进行对称加密

我们需要解决问题有:
1、认证客户端身份<

  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
先运行safechat包里的greetigserver.class,之后运行greetingclient.class即可。 如遇报错,请参考:https://blog.csdn.net/fengzun_yi/article/details/104497160 实现过程: 1. 采用TCP通信协议完成接收者发送者双方的消息传递。 2. 利用Diffie-Hellman密钥交换协议生成对称加密通信通信密钥。 3. 为防止中间人攻击,采用RSA非对称加密算法协助DH算法完成密钥交换。具体过程如下: a. 接收者与发送者双方各自利用RSA算法生成自己的公私钥,并生成数字证书,并在一个CA进行认证。 b. 在DH密钥交换阶段,A生成A的DH协商密钥用于发送给B,该密钥与接收方私钥生成最终通信密钥。发送DH密钥时,A先用自己的私钥加密DH协商密钥,再去CA获得一个真实的B的公钥,用B的公钥对加密过的协商密钥再做一次加密,发送给B。(因为是用B的公钥加密过,只有B有B的私钥,所以接收信息只有B自己可以解密查看,又因为是用A的私钥加密过的,只有A有A的私钥,所以只有用A的公钥可以进行解密,所以可以保证协商密钥确实是A发送过来的,而且发送的信息也无法被中间人解密。)B收到信息之后,先用自己的私钥解密,然后去CA获得A的公钥再对消息解密一次,获得A的DH密钥。B发给A的过程同上。 c. 之后双方执行DH生成本地密钥的过程。A利用B发送过来的密钥和A的DH私钥生成通信密钥。B利用A发送过来的密钥和B的DH私钥生成通信密钥。根据DH原理,两者生成的通信密钥是相同的。 4. 利用上一步生成的通信密钥,采用AES对称加密算法进行加密通信。 为了方便起见,并没用对A和B双方进行颁发证书的操作,A的公钥默认B已经从CA获得,B的公钥默认A已经从CA获得。并且采用java控制台交互,仅仅为演示原理及简单效果。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

程序员柒叔

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值