加密和签名方案

本文探讨了网络通信中的安全问题,通过四个场景分析了报文篡改和身份验证的需求。提出四种加密签名方案,包括对称加密签名机制、动态密钥加密、对称加非对称加密以及RSA签名结合HTTPS。这些方案旨在防止数据篡改并确保交易的不可抵赖性。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

场景一

转账交易:
假设我要做个转账的app叫支付宝,要完成转账的功能,转账时,需要输入对方支付宝账号和姓名,然后点击转账,输入支付密码,就可以完成转账的功能。
实现方式,客户端通过http协议发送转账报文给服务端 报文无加密和签名机制 现在用户甲要转账给用户乙

安全隐患

网络传输不安全,如果有人截取客户端请求报文,进行篡改,比如篡改收款方的支付宝账号和真实姓名,那么服务端就会把钱转到别的地方去。
结论:需要防止报文被篡改

场景二

某商城A要接支付宝移动支付,大致流程:
客户端app调用支付宝的sdk发送支付报文
客户端接收支付宝服务端的处理响应
商户服务端接收支付宝服务端的交易成功通知
客户端发送请求的安全隐患同场景一
服务端接收通知时,存在如下隐患,黑客甲,去商城A
人为模拟支付宝的通知报文,将订单变成成功。
这是一个通知报文要做签名的案例
需要注意的是,步骤2和3同样需要做签名验证
结论:需要确认报文来自真实合法的服务端(其实在商户对商户的通信过程中,也需要确认报文来自真实合法的客户端)
场景一和场景二的最终结论:
安全网络通信过程中,需要防止报文被篡改
安全网络通信过程中,需要客户端和服务端双方确认对方的身份,即交易完成后,不可抵赖

方案一 对称加密签名机制

具体方案:用一种对称加密算法将报文加密,并得出一个签名串
举例:MD5加密签名,签名串=md5(原文&密钥)(其他对称加密算法签名道理是一样的,不做详述)
假设最终的报文是:最终报文=原文&签名串
此方案达到的效果:
如果黑客截取报文,并篡改原文,那么服务端进行验签的时候,将不会通过。
因为原文变化了,算出的签名串会改变,那么黑客需要重新计算出签名串
要算出签名串,需要知道如下要素
签名算法(包含加密算法),原文,密钥 <

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值