美文网首页程序Android开发Java学习笔记
Android:Https + AES加密实现网络通信加密

Android:Https + AES加密实现网络通信加密

作者: 韩sang | 来源:发表于2016-08-09 17:06 被阅读2470次

    需求

    现在大多数的手机客户端采用Http+Json的方式与服务器进行通信,也有采用TCP+ProtoBuf实现,前者实现方便各种框架简单的就构建起了网络通信模块,后者的话需要强大的服务器性能,需要一定的技术储备,ProtoBuf基于二进制减少了传输的内容但不易阅读。我们使用抓包工具可以轻而易举的抓取Http传输的数据,有些竞品公司会通过抓包爬虫的方法抓取数据为己用,为防止这种情况,我们可以对数据加密。当然也能采用Https的方式通信,但是Https较低的传输效率,更大的耗电量,需要花钱购买SSL证书等缺点不是一个最佳的选择。本文采用的是对通信内容的加解密达到数据保护的效果。

    准备

    我们需要一种可逆的加密算法:AES加密,Android中对应的是这个类:Cipher,AES需要一些加密模式等的配置,想要了解的同学可以看一下这篇文章,不过也无关紧要

    对称加密和分组加密中的四种模式(ECB、CBC、CFB、OFB)

    另外我们需要一个校验算法:CRC校验,Android中对应的是这个类:CRC32

    AES加解密需要的password等是我们通过Https从服务器拉取,有关Https的配置使用,请参考这篇博客:

    Android Https相关完全解析

    思路

    Http里未做加密处理的body就是我们需要的Json数据的byte数组,现在需要对他的结构重新定义。重新定义的body结构包含三部分内容,一个头部分的字符串,这个头部分是和后端统一的一个乱码,主要是用来混淆视听的,没有特别的意义,简称为PRE,中间的这部分就是我们实际需要的json数据,简称为CONTENT,这部分内容是我们最终需要的数据,也是别人最想得到的,最后的一部分是一个CRC32的校验码,他是对PRE+CONTENT进行CRC校验得到的数据。为什么需要这个CRC校验码呢?是这样的,为了进一步增强数据的安全性,AES需要的password是定期更新的,当客户端拿到PRE+CONTENT这部分内容时会对这部分内容做一次CRC校验,得到的CRC码会与服务器返回的CRC32做比较,这两个不相等说明客户端与服务器端使用了不同的password加解密,这时客户端就要重新拉取最新的password并保存下来使用。举个栗子:你昨天晚上打开了app,拿到了password为123一切使用正常,第二天你有打开了app,在这之前服务器更换了password为456,你在未知的情况下使用123继续加解密,这时你们的crc码就会对不上,所以要重新拉取最新的password,这就是CRC32这部分的用处,实际就是一个双向校验的过程。

    代码

    首先先看Cipher这个类,它的init方法是这样的
    <pre>
    Cipher c = Cipher.getInstance("AES/CBC/PKCS5Padding");}
    参数对应的含义:"algorithm/mode/padding"
    </pre>

    所需参数需要和服务器端统一,这里我使用的是:

    <pre>
    private static final String CipherMode = "AES/CFB8/NoPadding";
    </pre>
    对于Http的get请求客户端要做的是对数据的解密:
    <pre>
    private static byte[] decrypt(byte[] content, String password, String iv) {
    try {
    SecretKeySpec key = createKey(password);
    Cipher cipher = Cipher.getInstance(CipherMode);
    cipher.init(Cipher.DECRYPT_MODE, key, createIV(iv));
    byte[] result = cipher.doFinal(content);
    return result;
    } catch (Exception e) {
    e.printStackTrace();
    }
    return null;
    }
    </pre>

    所需的参数 password,iv就是通过https获取的AES加密所需password与iv。
    这里还需要两个字符串转SecretKeySpec,IvParameterSpec的方法:

    <pre>
    private static SecretKeySpec createKey(String key) {
    byte[] data = null;
    if (key == null) {
    key = "";
    }
    StringBuffer sb = new StringBuffer(16);
    sb.append(key);
    while (sb.length() < 16) {
    sb.append("0");
    }
    if (sb.length() > 16) {
    sb.setLength(16);
    }

        try {
            data = sb.toString().getBytes("UTF-8");
        } catch (UnsupportedEncodingException e) {
            e.printStackTrace();
        }
        return new SecretKeySpec(data, "AES");
    }
    
    private static IvParameterSpec createIV(String password) {
        byte[] data = null;
        if (password == null) {
            password = "";
        }
        StringBuffer sb = new StringBuffer(16);
        sb.append(password);
        while (sb.length() < 16) {
            sb.append("0");
        }
        if (sb.length() > 16) {
            sb.setLength(16);
        }
    
        try {
            data = sb.toString().getBytes("UTF-8");
        } catch (UnsupportedEncodingException e) {
            e.printStackTrace();
        }
        return new IvParameterSpec(data);
    }
    

    </pre>

    接下来的代码就是按照思路进行CRC的校验,判断password,iv是否过期,解密是否成功。

    <pre>
    public static byte[] aesdeData(byte[] data,String key,String iv) {
    byte[] original = decrypt(data, key, iv);
    byte[] crc1 = Arrays.copyOfRange(original, original.length - 4, original.length);
    byte[] crc2 = new byte[8];
    for (int i=0;i<4;i++){
    crc2[i] = crc1[i];
    }
    ByteBuffer bf = ByteBuffer.wrap(crc2);
    bf = bf.order(ByteOrder.LITTLE_ENDIAN);
    byte[] temp = Arrays.copyOfRange(original, 0, original.length - 4);
    String result = new String(temp);
    byte[] datas = null;
    if (bf.getLong()==crc(temp)){
    result = result.replaceAll(PRE,"");
    datas = result.getBytes();
    }else {
    //key 失效
    result = null;
    datas = null;
    }
    return datas;
    }
    </pre>

    代码很清晰,先把原始数据做了一次解密,然后区后32位的CRC码,这个就是服务器对PRE+CONTENT的CRC校验的结果,然后我们对除掉后32位的数据进行CRC校验,这相当于客户端对PRE+CONTENT的CRC校验,两次校验的结果相等证明是一次成功的解密,这时就可以难道PRE+CONTENT的内容了,不要忘记去掉PRE部分才是我们真正需要的Json。如果CRC的结果不等证明key iv失效了需要重新获取。

    对于Http的post请求客户端要做的是对数据的加密:

    单纯加密的操作:
    <pre>
    private static byte[] encrypt(byte[] content, String password, String iv) {
    try {
    SecretKeySpec key = createKey(password);
    Cipher cipher = Cipher.getInstance(CipherMode);
    cipher.init(Cipher.ENCRYPT_MODE, key, createIV(iv));
    byte[] result = cipher.doFinal(content);
    return result;
    } catch (Exception e) {
    e.printStackTrace();
    }
    return null;
    }
    </pre>

    按照之前思路的加密:

    <pre>
    public static byte[] aesEn(String json, String key, String iv) {

        String preContent = PRE + json;
        long crc = crc(preContent);
        byte[] preData = preContent.getBytes();// 前缀和body的 String -> byte[]
        byte[] crcByte = longToByte(crc);//crc 64位 byte[]
        byte[] crcData = getCrcData(crcByte);//crc 32位byte[]
        byte[] finalData = byteMerger(preData, crcData);//最终需要加密的 byte[]
        byte[] enData = encrypt(finalData, key, iv);
        return enData;
    
    }
    

    </pre>

    代码很清晰就是对解密的逆操作

    完整的代码

    Github

    可能遇到的问题

    网络序字节序的问题,与服务器统一
    password iv失效造成加解密错误的情况,比较好的体验是用户无感知的情况下重新拉取password与iv并重复用户之前的请求,笔者配合的是Volley实现,不同框架的思路一致,这里不再讲解。

    END

    七夕快乐

    16-8-9 下午5.03 拍摄的照片.jpg

    相关文章

      网友评论

      • stone305585:韩sang 你这简书废弃了啊,果然飞黄腾达,不给我们这些屌丝普及姿势了
      • stone305585:不错的文章

      本文标题:Android:Https + AES加密实现网络通信加密

      本文链接:https://www.haomeiwen.com/subject/nqsdsttx.html