Android安全问题-网络传输

   <h2><strong>前言</strong></h2>    <p>Android开源，开源就意味着无线可能和无线的不安全。现在（2016）市面上的所有Android安全方法基本上有以下几种：</p>    <p>1.代码混淆。</p>    <p>2.so处理重要逻辑。</p>    <p>3.加壳</p>    <p>这些都是在客户端做的处理，然而，如果破解客户端能获取的利益大于破解的难度，那么基于开源的Android基本还是会被"破解大军"进行"三光政策"的。既然都会被破解，那还做这些做什么呢?这就是我之前文章说的，利益和难度的取舍。当我们做了以上3部后，就已经阻绝绝大部分的"破解军"，剩下的哪些顶尖人物怎么办呢？现在我的处理方法是放在服务端。</p>    <h2><strong>问题</strong></h2>    <p>要解决问题，首先要有问题，那么对于客户端来说什么是危险的呢？举个栗子，当用户注册的时候，如果明文传输就有可能被拦截到，泄漏用户密码的问题。正对这个问题，我来叙述一下自己的解决方案，顺便把这篇文章的重点带出来。</p>    <h2><strong>解决</strong></h2>    <p>问题：用户注册和服务端交互的信息有可能被拦截，导致账户等信息泄露。</p>    <p><strong>方法1</strong></p>    <p>将用户密码进行MD5后再传递。</p>    <p>这种方法也就保证了我们自己也无法知道用户的密码是什么。即使被拦截，破解军获取到这段信息也无法得知密码是什么。</p>    <p>PS:这种方法是可取的，但是如果用户的密码比较简单，那也是可以通过暴力破解出来的。所以MD5的方法比较适合用来确保数据的正确性，而不适合作为数据的保密处理。</p>    <p><strong>方法2</strong></p>    <p>使用特殊算法进行加密后在传递。</p>    <p>这种方法可以确保即使被拦截到信息，在不知道我们算法的前提下，破解军也无法获取有用信息。</p>    <p>不过这里有两个问题，第一是算法在破解后很容易查询到，即使是存放在so文件中。第二是这种自己定义算法对性能的要求可能比较高，毕竟我们又不是数学专家。</p>    <p>当然为了更坚固的堡垒，提高破解军的成本，该方法是可以结合使用的。</p>    <p><strong>方法3</strong></p>    <p>使用AES加密报文后在传递。</p>    <p>这种方法和方法2类似，只是AES是当下确定能很好加密数据，且很难暴力破解的方案。当然加密就要解密，而AES的加密和解密使用的通一个key值。那么就需要客户端存储一个key值，既然该key值存在客户端，那么破解的可能性就很大了。针对这个问题，有一个弯路可以考虑，那就是隐藏key值。</p>    <p>这里就记录一下隐藏key值的小故事，该方法不单是隐藏key值，也可以隐藏很多东西，增加破解的成本。</p>    <p>好，假设我们使用了AES加密，那么就有一个key值，那么我们应该怎么存这个key在客户端呢？</p>    <p>方法基本有以下这几种：</p>    <p>SharedPreferences</p>    <p>Java硬编码</p>    <p>NDK保存在so</p>    <p>发现，除了NDK的方法有点难度，其它两种基本都是新手破解军都能搞定的事，那么怎么办呢？那我就给他来个大杂烩别(年轻人啊)。首先我把key分成了4份。</p>    <p>key = "whitelaning";</p>    <p>key1 = "wh";</p>    <p>key2 = "ite";</p>    <p>key3 = "lan";</p>    <p>key4 = "ing";</p>    <p>当需要使用key的时候分别获取4段可以值合并后才能得到真正的key。</p>    <p><strong>key1写在string.xml中</strong></p>    <p>mContext().getResources().getString(R.string.something1); 。</p>    <p>ps:为什么叫something1呢，年轻人不懂事...</p>    <p><strong>key2写在AndroidManifest.xml中</strong></p>    <p><meta-data android:name="something2" android:value="ite"/> 。</p>    <p><strong>key3写在so文件中。</strong></p>    <pre>  <code class="language-java">#include "com_jni_JNIUtils.h"  JNIEXPORT jstring JNICALL Java_com_jni_JNIUtils_getString          (JNIEnv *env, jobject obj) {      return (*env)->NewStringUTF(env, "something3");  }    //---------------------------------------    key3 = new JNIUtils().getString();</code></pre>    <p><strong>key4写在assets的文件中。</strong></p>    <p>Context.getAssets().open(“something4.txt”)</p>    <p>然后...破解的难度提高了，而且也把以后的开发者逼疯了...哈哈...（弃用）</p>    <p><strong>方法4（使用中）</strong></p>    <p><strong>客户端 --> 服务端</strong></p>    <p>客户端使用随机生成的AES密钥加密传输数据，使用RSA公钥加密AES的密钥。</p>    <p>服务端使用RSA私钥解密出AES的密钥，再使用AES的密钥解密加密的数据。</p>    <p><strong>服务端 --> 客户端</strong></p>    <p>服务端使用RSA解密出AES的密钥后，使用该AES密钥解密数据，然后进行业务处理。业务处理完毕后，使用该AES密钥对数据进行加密，返回给客户端。</p>    <p>客户端接收到返回数据后，使用之前请求时随机生成的AES密钥进行解析，然后废弃该AES密钥。</p>    <p>以上就是一次完整的请求交互过程，当然省略了一些细节上的处理和具体业务。比如数据应该使用MD5来验证数据的完整性，接口验证等等。</p>    <p>方法4有点类似 SSL/TLS 协议握手的原理，当然因为Android是开源的，没必要完全按照 SSL/TLS 协议来实现，毕竟做安全问题的时候，我都是默认我的源码被盗了的情况下去做的。</p>    <p> </p>    <p> </p>    <p>来自：http://www.jianshu.com/p/84636b4b21d2</p>    <p> </p>