加密和签名方案

场景一
转帐交易：
假设我要作个转帐的app叫支付宝，要完成转帐的功能，转帐时，须要输入对方支付宝帐号和姓名，而后点击转帐，输入支付密码，就能够完成转帐的功能。
实现方式，客户端经过http协议发送转帐报文给服务端
报文无加密和签名机制
如今用户甲要转帐给用户乙。
安全隐患
网络传输不安全，若是有人截取客户端请求报文，进行篡改，好比篡改收款方的支付宝帐号和真实姓名，那么服务端就会把钱转到别的地方去。
结论：须要防止报文被篡改
场景二
某商城A要接支付宝移动支付，大体流程：

1. 客户端app调用支付宝的sdk发送支付报文
2. 客户端接收支付宝服务端的处理响应
3. 商户服务端接收支付宝服务端的交易成功通知
   客户端发送请求的安全隐患同场景一
   服务端接收通知时，存在以下隐患，黑客甲，去商城A
   人为模拟支付宝的通知报文，将订单变成成功。
   这是一个通知报文要作签名的案例
   须要注意的是，步骤2和3一样须要作签名验证
   结论：须要确认报文来自真实合法的服务端（其实在商户对商户的通讯过程当中，也须要确认报文来自真实合法的客户端）

场景一和场景二的最终结论：

1. 安全网络通讯过程当中，须要防止报文被篡改
2. 安全网络通讯过程当中，须要客户端和服务端双方确认对方的身份，即交易完成后，不可抵赖

方案一 对称加密签名机制
具体方案：用一种对称加密算法将报文加密，并得出一个签名串
举例：MD5加密签名，签名串=md5(原文&密钥)（其余对称加密算法签名道理是同样的，不作详述）
假设最终的报文是：最终报文=原文&签名串
此方案达到的效果：
若是黑客截取报文，并篡改原文，那么服务端进行验签的时候，将不会经过。
由于原文变化了，算出的签名串会改变，那么黑客须要从新计算出签名串
要算出签名串，须要知道以下要素
签名算法（包含加密算法），原文，密钥
前2个确定是会暴露的，没法保密，而客户端是app，密钥也是暴露的，因此签名串会被从新计算出来，所以黑客将成功篡改转帐报文。
方案二 对称加密签名，动态密钥
从方案一咱们得出一个结论：
签名算法（包含加密算法），原文，密钥三者只要保证其中一个不被黑客截取，将没法算出签名串，也就没法篡改报文。
那么咱们能够动态生成签名的密钥，并用rsa公钥对其进行加密（此处rsa私钥在服务端，不会泄密，由于签名密钥不会被解密），而后传至服务端
次方案用于场景一，能够解决报文被篡改的问题。
可是服务端就没法确认客户端是否合法，尤为在机构与机构通讯的时候，这个方案就更不可取。
且次方案不适合于方案2，支付宝服务端发通知的时候，总不能动态产生密钥，这样你就没法断定报文是不是支付宝服务端发送来的。
方案三 报文加密（对称加非对称）
从方案一咱们得出一个结论：
签名算法（包含加密算法），原文，密钥三者只要保证其中一个不被黑客截取，将没法算出签名串，也就没法篡改报文。
那么咱们就采起对报文加密，可用方式是对称加密和非对称加密
1.对称加密：3des
签名串=md5(原文&密钥1)
最终报文=3des密钥2&签名串
传输过程当中，报文是加密的，没法篡改（由于没法拿到用户关键信息，如session，tokenId等认证信息），看似没有问题，可是密钥1和密钥2均可能泄密，并且3des会被解密掉，因此又回到方案一的结果。
2.非对称加密+对称加密：3des+rsa+md5
那么咱们能够从方案二吸收经验，用rsa密钥加密对称加密密钥
签名串=md5(原文&密钥1)
最终报文=3des密钥2|签名串|rsarsa公钥
此方案仍然有方案二的缺陷，只能解决场景1，不能解决场景2
缘由在于签名的密钥，服务端和客户端是同样的，没法产生惟一性身份
咱们须要用rsa来签名

方案四 rsa签名+https
报文加密是必须的，那么咱们用https加密，其原理同非对称加密+对称加密
场景一方案：
客户端产生一对公私钥 pubKey_c，priKey_c
服务端产生一对公私钥 pubkey_s，priKey_s
客户端与服务端置换公钥
最终持有状况以下：
客户端：pubkey_s，priKey_c
服务端：pubKey_c，priKey_s
客户端发送报文：
签名串=rsapriKey_c
最终报文=https(报文原文+签名串);
场景二，相对于场景二
服务端用pubKey_c作验签，
产生效果：客户端私钥priKey_c没有被盗取时，能够防止报文被篡改，且服务端能够确认信息来自合法的客户端，在机构与机构通讯时，次种假设是成立的。
客户端是app, 客户端私钥priKey_c会被盗取，不能保证客户端的合法性（即客户端能够不是官方提供的），但仍然能够防止报文被篡改。
服务端响应报文时：
签名串=rsapriKey_s
最终报文=https(报文原文+签名串);
产生效果：由于服务端的私钥priKey_s在理论上是不会泄密的，因此能够保证响应报文不会被篡改，且来自真实合法的服务端
场景二方案：
支付宝服务端发送报文：
签名串=rsapriKey_s
最终报文=https(报文原文+签名串);
客户端用pubkey_s来验签便可，可保证，报文不会被篡改，且来自真实合法的服务端