移动端与后端数据传输加密

对称加密：对称加密加密与解密使用的是同样的密钥，所以速度快，但由于需要将密钥在网络传输，所以安全性不高

非对称加密：非对称加密使用了一对密钥，公钥与私钥，所以安全性高，但加密与解密速度慢。

方案：将对称加密的密钥使用非对称加密的公钥进行加密，然后发送出去，接收方使用私钥进行解密得到对称加密的密钥，然后双方可以使用对称加密来进行沟通。

方案的流程介绍：

1、APP客户端需要和服务器进行数据交互，它的APP首先生成了一个随机数作为对称密钥(比如AES加密的密钥)。

2、APP客户端向服务器请求公钥

3、服务器将公钥发送给APP客户端

4、APP客户端使用服务器的公钥将自己的对称密钥(比如AES加密的密钥)加密

5、APP客户端将加密后的对称密钥发送给服务器

6、服务器使用私钥解密得到APP客户端的对称密钥

7、APP客户端与服务器可以使用对称密钥来对沟通的内容进行加密与解密了

App端和后台数据加密分两部分：

1.数据传输的时候加密 （一般采用Https协议在传输层加密）

2.数据本身的加密（使用各种加密算法）

RSA非对称加密：公钥加密，私钥解密。公钥私钥由服务端生成，公钥放在客户端私密保存，私钥放在服务端。安全性高，运算速度慢

AES对成加密：运算速度快切安全性高

上面网络通信过程是安全的，可以保证通信数据即使被截取了，也无法获得任何有效信息；即使被篡改了，也无法被客户端和服务端验证通过。

具体可参考的博文：（记得后续实践哦）

https://blog.csdn.net/wangjiang_qianmo/article/details/88073848?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-1.channel_param&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-1.channel_param

粗略地分析， 登录机制主要分为登录验证、登录保持、登出三个部分。登录验证是指客户端提供用户名和密码，向服务器提出登录请求，服务器判断客户端是否可以登录并向客户端确认。 登录认保持是指客户端登录后， 服务器能够分辨出已登录的客户端，并为其持续提供登录权限的服务器。登出是指客户端主动退出登录状态。容易想到的方案是，客户端登录成功后， 服务器为其分配sessionId, 客户端随后每次请求资源时都带上sessionId。

上述简易的登录验证策略存在明显的安全漏洞,需要优化。

客户端第一次发出登录请求时， 用户密码以明文的方式传输， 一旦被截获， 后果严重。因此密码需要加密，例如可采用RSA非对称加密。具体流程如下：

再仔细核对上述登录流程， 我们发现服务器判断用户是否登录， 完全依赖于sessionId, 一旦其被截获， 黑客就能够模拟出用户的请求。于是我们需要引入token的概念： 用户登录成功后， 服务器不但为其分配了sessionId, 还分配了token， token是维持登录状态的关键秘密数据。在服务器向客户端发送的token数据，也需要加密。于是一次登录的细节再次扩展。

在最原始的方案中， 登录保持仅仅靠服务器生成的sessionId: 客户端的请求中带上sessionId, 如果服务器的redis中存在这个id，就认为请求来自相应的登录客户端。 但是只要sessionId被截获， 请求就可以为伪造， 存在安全隐患。

引入token后，上述问题便可得到解决。 服务器将token和其它的一些变量， 利用散列加密算法得到签名后，连同sessionId一并发送给服务器； 服务器取出保存于服务器端的token,利用相同的法则生成校验签名， 如果客户端签名与服务器的校验签名一致， 就认为请求来自登录的客户端。

1.3 TOKEN失效

用户登录出系统

失效原理：

在服务器端的redis中删除相应key为session的键值对。

App因为要实现自动登陆功能，所以必然要保存一些凭据，所以比较复杂。

App登陆要实现的功能：

这里判断时间，主要是防止攻击者截取到加密串后，可以长久地利用这个加密串来登陆。

不用AES加密，用RSA公钥加密也是可以的。AES速度比RSA要快，RSA只能存储有限的数据。

可以加密。先来说一下一些常用的加密方法：

伪加密

伪加密是Android4.2.x系统发布前的加密方式之一，通过java代码对APK(压缩文件)进行伪加密，其修改原理是修改连续4位字节标记为”P K 01 02”的后第5位字节，奇数表示不加密偶数表示加密。

虽然伪加密可以起到一定防破解作用，但也会出现问题，首先使用伪加密对其APK加密后市场无法对其进行安全检测，导致部分市场会拒绝这类APK上传；其次，伪加密的加密方式和解密方式也早已公布导致它的安全程度也大大降低；再次，Android4.2.x系统无法安装伪加密的APK；最后伪加密只是对APK做简单保护，在java层源码加壳保护、核心so库、资源文件、主配文件、第三方架包方面却没有任何保护处理。注意：高版本不支持这样的方法，所以还是不要尝试使用这样的加密方式了。

混淆保护

把原来有具体含义的类名，变量名，方法名，修改成让人看不懂的名字，例如方法名getUserName编程了方法名

破解：耐心

运行时验证

运行时验证，主要是指在代码启动的时候本地获取签名信息然后对签名信息进行检验来判断自己的应用是否是正版，如果签名信息不是正版则提示盗版或者直接崩溃。当然你可以把必要的数据放在服务器端。

破解：找到smali文件中，判断是否相等的部分。改为常量true,即失效。

总之，反编译一些apk之后，只要是java代码写的总会有smil文件。对于smil文件，如果耐心读的话，还是可以查看到一些关键代码的。

相较于应用来说，游戏apk因为采用cocos2d-x 或者 unity3D，采用的是c++ 和c# 编写的跨平台程序，在apk采用JNI的方式。所以没有smali，可以防止静态被破解apk包。

当然游戏包apk 在运行的时候，会把.*so加载到内存中。动态也是可以在内存中抓取相应的数据。只不NDK 相对于smali破解来说，根部不是一个层级的关系。

---