前后端分离项目接口数据加密的秘钥交换逻辑(RSA、AES)
2020年03月25日 12:01:54 · 本文共 1,524 字阅读时间约 5分钟 · 12,600 次浏览在前后端分离的项目中,往往需要传输一些敏感的信息,例如密码、金额等,签名验签算法只能保证数据不被篡改,但是却无法对数据进行保密,如果用户输入的密码明文传输,就会被网络中的节点截获,虽然大部分网络运营商并不会去截取网络传输的内容,但是不能排除用户连接的WiFi网络是不是钓鱼网络,所以在传输敏感信息的时候需要加密,本文就讨论如何安全的让客户端和服务器交换秘钥。
加密算法的选择,RSA还是AES
涉及到加解密就涉及到加解密算法的选择,比较常见的是非对称加密RSA和对称加密AES,它们各有什么特点和选择呢?我们逐个说明
RSA非对称加密
RSA算法会生成两个秘钥,一个公钥,一个私钥,使用公钥加密的数据必须使用私钥解密,这样的好处是只有服务器有私钥,其他人无法解密。但是他有个非常致命的弱点,那就是加密内容的长度不能大于秘钥长度,以RSA 1024为例,PKCS#1建议的padding占用了11个字节,这样,128字节(1024bits)-减去11字节是117字节,也就是说我们使用RSA 1024最多只能加密117字节的内容,如果超过这个内容就会报错,可往往我们要传输的内容非常庞大,我们也不能无限制的增加秘钥长度。而且在移动设备上性能有限,并不适合大量加解密运算。所以我们还需AES。
AES对称加密
因为上述的RSA受到秘钥长度的加密限制,我们还需要AES加密,AES的优点是无论明文有多大它都可以加解密。但是缺点是它不区分私钥和公钥,密钥只有一个,任何知道秘钥的人都可以加解密信息。
RSA和AES结合使用取长补短
RSA和AES都有各自的优缺点,如果我们把他们结合使用就可以取长补短,我们可以使用RSA来保护AES的秘钥,这样可以保证只有双方知道AES的秘钥,并且AES可以加密任何长度的信息,这样就解决了它们各自的缺点。
秘钥交换逻辑
一、客户端向服务器端申请RSA公钥;服务器生成一个RSA秘钥对,将公钥发送给客户端。我们起名为「Server公钥」
二、客户端收到服务器给出的「Server公钥」,客户端生成自己的RSA秘钥对,我们起名为「Client公钥」,客户端使用「Server公钥」去加密自己的「Client公钥」,发送给服务器
三、服务器收到客户端的请求,使用「Server私钥」解密得到「Client公钥」
四、服务器生成一个「AES秘钥」,使用「Client公钥」加密「AES秘钥」发送给客户端
五、客户端使用「Client私钥」解密得到「AES秘钥」
后续双方的交互使用「AES秘钥」进行加解密,秘钥交换流程完成。
实例代码:
@Test
public void reaTest() {
//服务器端的
Map<Integer, String> serverKeyMap = RSAUtils.genKeyPair(2048);
//客户端的
Map<Integer, String> clientKeyMap = RSAUtils.genKeyPair(1024);
String clientPubKey = clientKeyMap.get(0);
try {
//客户端使用服务器公钥加密自己的公钥
String encrypt = RSAUtils.encrypt(clientPubKey, serverKeyMap.get(0));
//服务器端使用自己的私钥解密拿到客户端公钥
Assert.assertEquals(clientPubKey, RSAUtils.decrypt(encrypt, serverKeyMap.get(1)));
String AESkey = "aeskey123456";
//使用客户端的公钥加密AES的秘钥
String encryptAES = RSAUtils.encrypt(AESkey, clientPubKey);
//客户端用自己的私钥解密拿到AES的秘钥
Assert.assertEquals(AESkey, RSAUtils.decrypt(encryptAES, clientKeyMap.get(1)));
} catch (Exception ex) {
ex.printStackTrace();
Assert.assertNull(ex);
}
}
版权声明:本文为博主「任霏」原创文章,遵循 CC BY-NC-SA 4.0 版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.renfei.net/posts/1003346
相关推荐
猜你还喜欢这些内容,不妨试试阅读一下以下内容均由网友提交发布,版权与真实性无法查证,请自行辨别。
请问在上面的这个流程中,如果在第一步客户端向浏览器请求公钥因为是走明文的,如果这时候服务端返回的公钥被中间人替换掉了,中间人把自己的公钥给到前端,这样后续的请求是不是就就不再安全了?这样的话这个流程是不是可以认为不算是安全的呢?
关于中间人攻击,就需要引入第三方来解决信任问题,https 的 ssl 证书就可以,比如我请求www.renfei.net,你说你(中间人)是www.renfei.net,那你就出具 ssl 证书证明你是,如果证书对不上,那我就不信任你,不会继续交换秘钥了。申请 ssl 证书的时候会审核域名所有权,不是随便就能申请的,所以假冒的服务器端(中间人)是无法出具证书证明自己是www.renfei.net的。
您好,对于秘钥交换逻辑有个问题,为何我前端还要在生成一次RSA秘钥给到后端公钥,然后由后端生成AES对称秘钥给前端呢,如果是前端生成AES对象秘钥然后通过后端的公钥加密给到后端,这样会有什么风险吗? 一、客户端向服务器端申请RSA公钥;服务器生成一个RSA秘钥对,将公钥发送给客户端。我们起名为「Server公钥」 二、客户端收到服务器给出的「Server公钥」,客户端生成一个「AES秘钥」,客户端使用「Server公钥」去加密自己的「AES秘钥」,发送给服务器 三、服务器客户端使用「Server私钥」解密客户端发送的「AES秘钥」进行存储
您是说服务器端生成的RSA私钥吗,服务器在生成RSA秘钥对的时候同时产生一个KeyID,保存在数据库中,向客户端发送「公钥」的时候会告知客户端秘钥的KeyID;客户端下次发送加密后的内容时需要带上KeyID,这样服务器就知道客户端目前使用的是哪套秘钥对了,同时你也可以在服务器端存储的时候给秘钥对设置有效期,比如7天以后这套秘钥对作废。
- 前后端分离项目接口数据加密的秘钥交换逻辑(RSA、AES)
- OmniGraffle 激活/破解 密钥/密匙/Key/License
- 人大金仓 KingbaseES V8 R3 安装包、驱动包和 License 下载地址
- Parallels Desktop For Mac 16.0.1.48911 破解版 [TNT]
- Redis 未授权访问漏洞分析 cleanfda 脚本复现漏洞挖矿
- CleanMyMac X 破解版 [TNT] 4.6.0
- OmniPlan 激活/破解 密钥/密匙/Key/License
- Parallels Desktop For Mac 15.1.4.47270 破解版 [TNT]
- Sound Control 破解版 2.4.2
- 向谷歌搜索引擎主动推送网页的教程 Google Indexing API 接口实现
- 博客完全迁移上阿里云,我所使用的阿里云架构
- 微软确认Windows 10存在bug 部分电脑升级后被冻结
- 大佬们在说的AQS,到底啥是个AQS(AbstractQueuedSynchronizer)同步队列
- 比特币(BTC)钱包客户端区块链数据同步慢,区块链数据离线下载
- Java中说的CAS(compare and swap)是个啥
- 小心免费主题!那些WordPress主题后门,一招拥有管理员权限
- 强烈谴责[wamae.win]恶意反向代理我站并篡改我站网页
- 讨论下Java中的volatile和JMM(Java Memory Model)Java内存模型
- 新版个人网站 NEILREN4J 上线并开源程序源码
- 我站近期遭受到恶意不友好访问攻击公告