客户端/服务器 http加密方案----对称与非对称加密_系统中服务端存储的人机账号口令信息采用对称加密

加密技术一般分为两类 
1.对称加密,即加密与解密用的是同一把秘钥,常用的对称加密技术有DES,3DES,AES. 
2.非对称加密,加密与解密用的是不同的秘钥,常用的非对称加密技术有RSA.

下面举例默认是用客户端（app）—服务器（server）通过http交互的。

对称加密： 
优点：速度快 
缺点：加密和解密的钥匙必须相同，只有通信双方才能知道密钥。

详解：当客户端或者服务器生成秘钥后，通过网络传输给对方，很容易被截取秘钥，（这就是 HTTP 传输所面临的问题之一：中间人攻击，指消息传递的过程中，处在传递路径上的攻击者可以嗅探或者窃听传输数据的内容。）不安全。当然有人考虑说，服务器跟客户端私下约定一个秘钥用于加解密，这样秘钥都是线下的，只有两端的开发人员知道，而且AES 在数学上保证了，只要你使用的 key 足够长，破解几乎是不可能的，但是万一密码泄露，app不能热更新的情况下，想要换秘钥是要很长的时间，这段时间内，损失不可估量。

非对称加密： 
优点：算法更加复杂，加密和解密钥匙不相同，任何人都可以知道公钥，只有一个人持有私钥可以解密。 
缺点：非对称加密算法的开销很大,所以如果直接以非对称技术来加密发送的消息效率会很差。

详解：客户端跟服务器都有两把秘钥，及公钥跟私钥。服务器用客户端的公钥加密的密文，只有用客户端的私钥才可以解密，同理，客户端用服务器的公钥加密的密文，只有服务器的私钥才可以解密，而服务器或者客户端的公钥可以公布出去，但是私钥都在各自手中，只有用他们自己的私钥才可以解密，保证安全。但是非对称加密效率差，所以有人提出如下把对称加密技术与非对称加密技术结合起来使用.

思想：数据加密用对称加密，对称加密的秘钥通过非对称加密传输。 
例:客户端要发送一个消息给服务器. 
一,客户端先随机生成一个对称秘钥,这个秘钥可以是随机生成的, 
二,客户端用服务器的公钥加密第一步生成的这个对称秘钥 
三,客户端把加密过的对称秘钥通过http请求发给服务器 
四,客户端用第一步生成的这个对称秘钥加密实际要发的消息，并发给服务器 
对于服务器 
他先收到客户端发来的对称秘钥,这个秘钥是用自己的公钥加密过的,所以服务器需要用自己的私钥来解密这个秘钥 
然后服务器又收到客户端发来的密文,这时候用刚才解密出来的秘钥来解密密文。

这样的思路猛的一看没有问题，其实是不安全的，由于服务器的公钥是开放的，其他人可以用服务器的秘钥加密自己的一个秘钥发给服务器，这个时候，服务器误认为是客户端发的，则用自己的私钥解密后得到对称加密的秘钥，之后的数据传输则用错误的秘钥在加密，而攻击者则轻易的看到所有的数据。

**解决办法就是改造一下上面的步骤： 
1，客户端用服务器的公钥加密应用程序的keystore（md5加密后的），发送到服务器，服务器接收到后用私钥解密，跟事先保留keystore的md5值做匹配，看是否一致（防止二次打包跟数据来源不合法） 
2，请求来源合法后，服务器用md5加密后的keystore作为对称加密的key加密临时秘钥，再用私钥加密，传给客户端。 
3，客户端收到后，用服务器的公钥解密，同时，用md5加密的keystore解密出临时秘钥。 
4，后面的数据交互，都用该临时秘钥加解密。**

获取keystore代码如下所示：

 public String getSingInfo() {
        String signkey = "";
        try {
            PackageInfo packageInfo = getPackageManager().getPackageInfo("focus.teach.myapplication", PackageManager.GET_SIGNATURES);
            android.content.pm.Signature[] signs = packageInfo.signatures;
            Signature sign = signs[0];
            signkey = parseSignature(sign.toByteArray());
        } catch (Exception e) {
            e.printStackTrace();
        }
        return signkey;
    }
 
 
    public String parseSignature(byte[] signature) {
        String pubKey = "";
        try {
            CertificateFactory certFactory = CertificateFactory.getInstance("X.509");
            X509Certificate cert = (X509Certificate) certFactory.generateCertificate(new ByteArrayInputStream(signature));
            pubKey = cert.getPublicKey().toString();
        } catch (CertificateException e) {
            e.printStackTrace();
        }
        return pubKey;
    }
   
   
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

还有一种方案，改造了对称加密，融合进非对称加密的思想，方案如下： 
1.同样两个秘钥，一个秘钥保存在客户端，通过jni，打在so中，同时服务器也清楚该秘钥内容，一个秘钥保存在服务端，根据token值不同而不同，可以动态变化。 
2.登录返回的时候，服务器用客户端的秘钥加密自己的秘钥，通过http 返回给客户端。 
3.客户端拿到服务器的加密秘钥后，通过本地的秘钥解密，得到服务器的秘钥，之后所有的数据请求都用服务器秘钥通过对称加密进行。

当然这个方案也有缺陷： 
1.上次听网易的哥们说，so也可以被反编译出来，所以秘钥打在so里面还是不安全。 
2.如果客户端秘钥泄露，其实跟原始的对称加密一样没有办法快速修复。

大家有什么好的建议，欢迎留言共同探讨。