Ms-pingan的加密
对请求体做Hash加密生成固定长度的密文A1。加密算法SHA-256.
对请求方法类型（POST）+请求地址+请求头（Content-Type，X-Appid，X-Deviceid，X-Timestamp）+请求体密文A1+appkey通过加密算法生成签名，把签名放入请求头（X-Authorization）。
生成签名的加密算法：拼接数据；对拼接数据做SHA-256加密得到密文；通过密钥appkey对密文做SHA-256加密得到签名。
平安受到请求后，获取请求头的appID，查询得到对应的appKey，再对请求头和请求体明文，使用系统的加密算法得到签名，通过比对签名校验数据的一致性。
结论：平安的这种方案解决了一半的问题。即对平安的请求接口的数据的一致性校验的问题。但是平安返回的校验结果的数据一致性问题没有解决。攻击者可以拦截并篡改返回的校验结果。
Ms-ibss的加密
激活页面：
1、 前端调用后端ms-ibss，调用ibss/init，请求头RqUuid，ClientId，ClientCountry，TraxDateTime，请求体RAOCaseId，UniqueId，IPAddress，DeviceId。如果返回成功，ms-ibss用uniqueId生成JWT，返回给rao，返回给前端。
前端调用bff，前端传递IPAddress，DeviceId。
Bff调用rao，rao从请求头获取applicationId，即RAOCaseId。
Rao调用ms-ibss，rao通过工具类生成随机数uniqueID。
Ms-ibss生成JWT：从本地密钥文件rao-keystore-4096.jks获取keystore，通过别名（mscp-dev/prod.ocbcgroup.ocbc.com）从keystore获取公钥，通过别名和密码获取私钥。再通过UniqueID和expireDate生成JWT。
ms-ibss，把uniqueId和expireDate放入payload，通过私钥加密得到签名部分，调用hk ibss传递参数（raoCaseId, uniqueId, ipAddress, deviceId）,返回JWT给前端。
ibss不需要用私钥进行加密得到JWT；ibss用公钥对JWT进行解码得到uniqueId，跟请求参数进行比对校验一致性；然后把参数存储到数据库。
2、 前端调用IBSS/isEligible校验JWT
前端传递（deviceId，JWT），IBSS校验JWT，包括签名有效性，在有效期内，数据一致性。成功则返回E2EE.Public Key Module（公钥），Public Key Exponent， 3DES Key Length。前端存储上述参数到encryted store。
3、 用户输入用户名和密码
4、 前端调用IBSS/create
前端获取存储的key，调用E2EE.Js对密码做对称加密；前端调用IBSS/create，传递JWT和账户名和（加过密的）密码。IBSS校验JWT；IBSS注册并激活账户名和密码。
注：IBSS负责JWT的校验；JWT同RAOCaseId，UniqueId，IPAddress，DeviceId绑定，意味着注册过的deviceId是否可以再用，取决于IBSS绑定的强弱；
调用isEligible时，JWT的作用是设备校验的数字签名；
调用create时，账户成功激活后把账户名密码同JWT绑定；估计账户激活，用户登录及以后的操作，都会把JWT作为身份校验的数字签名。
设备校验：IBSS通过JWT获取关联对应的UniqueId和deviceID，同前端传递的DeviceID进行比对。
问题：ibss作为了鉴权中心，每次请求都要通过ibss校验JWT。失去了JWT的意义。
前端调用hk ibss时传递参数（deviceId，JWT），ibss对JWT的签名部分通过公钥解密得到明文，获得uniqueId，查询得到关联的deviceId，比对请求的参数（deviceId）进行校验。