ios客户端请求数据加密方式

商业App，在客户端与服务端做通讯时，通讯内容都要进行严格加密，以防止第三方的一些攻击与请求伪造。尤其涉及支付等需要安全性比较高的业务的时候。

下面是记录我参与的app，XX音乐的加密方式。以防细节遗忘。

先说一下大背景：

工程用的请求类是ASIHttpRequest，为了做加密层，我把ASI又封装了一层，继承于ASI,以供加密技术的实现。数据加密整体是在request  init的时候做的，加密完，再调super 的 init。

调完super 的 init 构造好request后，要在request得请求头里打入一些标签，以供客户端和服务端交互使用。具体下面说。

加密方式为RC4，为了防止反编译（有安卓版本，安卓端反编译比较严重），直接用c实现的，然后打包.a库文件放在工程里。

1.加密方式

以一条标准请求url为例：

http://m.zhangsan.cn/sod?action=6&parameter={userID=400802759}

1>get请求

其中，前半部分不做加密，为访问服务器的基本地址，后半部分用于数据传递的部分，要做加密，我们用的为RC4.

2>post请求

post请求，后面的数据部分，会放在post请求体里。

其实这里要加密的数据在请求init的时候就会开始做加密处理，加密好之后，调[superinitWithURL:newURL] ，这里的super，其实就是ASIHttpRequest，至于是拼到基本地址后面，还是放到post里，要看当前客户端和服务端的交互方式来决定。

2.请求头里的标签

加密后的数据，要往请求头里打入一些标签，以供服务端识别。我们有的标签包括：

X-AC:用户authcode，登陆用户会分配一个acthcode，这个其实是用于区分当前请求发送的客户端是否是登陆用户。如果是游客访问，头里不会有这个字段。

X-CID:是当前设备的唯一标示符，生成方式为openUDID

X-PRODUCT:ios/Android以及版本号

X-SEC:加密方式，我们的分为P,C 和 P，P,C代表为私钥加密，P代表为公钥加密，需要服务器对应的解密方式来解密。

3.错误处理机制

这里的错误有几个场景。

解密失败、XCID对应的解密key不存在或者无效、不支持的加密算法、数据错误。大概就这些，分别对应不同的处理方式。但我们的处理方式都很通用，就是如果遇到错误，先用公钥进行加密完成请求，然后重新请求私钥，并保存，之后的请求用新的私钥进行加密。

这里还有一个错误上限机制，同一个请求最多允许被连发三次，如果一个请求连续三次被解密失败，则会认为请求失败，并给出相应的提示给用户。

譬如请求用私钥第一次失败了，然后用公钥加密继续发又失败了，下一次的时候用新请求回来得私钥发，还是失败，然后又用公钥继续发，如果还失败，那么这个请求就不发了，直接认为请求失败，并提示相关提示给用户。

4.流程

进入app-》记录存放秘钥的目录-》记录版本号，x-ac，x-cid以供请求头用-》发请求获取私钥并保存（加密方式用公钥）

之后就进入正常的加密请求。

5.解密

解密相对简单，请求返回的json串是整体加了密的，只要用正确的解钥去解密，然后获得明文，解析就ok了。