iOS 和服务端交互 数据加密策略

总体逻辑：

客户端：对称加密数据，上传。。。回执对称解密

同理服务端：获取上传数据 对称解密 。。。下发：对称加密

当且仅当登录接口和 拉新（更新nonce 和 key的接口）是对称加密上传 非对称解密

 

1.加密库选择 ： Libsodium

2.加密对象：     

（1）整体：这个我们最后放弃了，因为如果整体加密，服务端大多数情况会回执本地无法解开的数据，客户端不能按需处理逻辑了，僵死的逻辑处境

（2）局部：只加密data部分，这样随时根据回执信息按需处理

　　　　　　{code:0

                 data: {XXX}

　　　　  　message:success　　　　　　

　　　　　　}

 

3.加密方式：

重中之重，先 生成密钥对：

执行方法crypto_box_keypair，生成密钥对（pk,sk）

3.1 未登录前http请求需要：(eg 发送验证码、请求国际码集合等)

对称加密：

客户端参数：

  (1)前提:请求头必有参数

  VERSION:客户端版本号 md5处理

（2）密码学必要参数 nonce:  (1) 中截取md5[0,24)

          key:  (1)中截取[0,32)

  (3) 加密对象：最终转为data形式

 (4)执行加密传输：

                                                       方法：crypto_secretbox_easy

同理：服务端解密需要用 成对方法解密：crypto_secretbox_open_easy

 

（5）服务端回执：客户端对称解密（服务端发送是对称加密）

 

3.2 登录操作：

（1） “3.1”  对称加密形式发起登录请求

（2） 上传加密的内容包括 本地生成的pk. 👌登录操作上传公钥对

（3）服务端回执：新的nonce 和 key  更新并存储 （此时回执解密使用非对称解密）

         服务端非对称加密方法： crypto_secretbox_easy

         客户端非对称解密方法： crypto_secretbox_open_easy

3.3 登录后的所有http请求（客户端继续操作）

    （1）发起请求，上传 对称加密

    （2）回执： 对称解密

    （3）当验签失败 即接口401时，seed(即  nonce 和 key 过期)，使用更新 seed接口，再次更新nonce和key 再继续请求。（这个交互逻辑类似于钉钉，异端登录会踢掉该账号，要重新登录才能继续使用的业务逻辑）

         更新nonce 和 key 操作 因为 旧的已失效

    （4）👌该拉新接口：对称加密（实际好像没参数。。。看需求 有就对称加密上传）上传，非对称解密更新nonce和key

     

待有时间，细化该文章。。。