美文网首页iOS收藏iOS BlogIOS开发资料库
结合RSA,AES128,MD5---移动端与服务端在通信层的加

结合RSA,AES128,MD5---移动端与服务端在通信层的加

作者: mdiep | 来源:发表于2017-01-06 14:15 被阅读2578次

很高兴能在项目中使用到RSA,AES128,以及MD5,用以保证客户端(Client)和服务端(Server)之间的通信安全。接下来会尽力的描述清楚关于本次使用的流程。具体关于算法的细节,自行Wiki。

原来只是对加密这一块很简单的了解,比如只知道一些对称加密,非对称加密,md5单向加密等。通过本次的学习,很惊艳于可以将多种加密方式那么完美的结合到一起。让整个通信过程变得如此美妙。虽然增加了服务端和客户端的工作量,但是保证数据的一致出口,一致入口,只需要在出口和入口处加上逻辑,就可以很好的避免扰乱原有逻辑的烦恼。

简单的概念,文章可能会涉及到

  1. RSA——非对称加密,会产生公钥和私钥,公钥在客户端,私钥在服务端。公钥用于加密,私钥用于解密。
  2. AES——对称加密,直接使用给定的秘钥加密,使用给定的秘钥解密。(加密解密使用相同的秘钥)
  3. MD5——一种单向的加密方式,只能加密,不能解密
  4. Base64编码——对字节数组转换成字符串的一种编码方式

客户端,服务端的通信逻辑

之前:明文传输通信

  1. 客户端将要上传的数据以字典(Map)的方式打包,Post提交给服务器。
  2. 服务器接收提交的数据包,通过Key-Value的形式获取客户端提交的值,进行处理。
  3. 处理结束,将数据以字典(Map)的形式打包,返回给客户端处理。

加密传输通信

整个流程是:

客户端上传数据加密 ==> 服务器获取数据解密 ==> 服务器返回数据加密 ==> 客户端获取数据解密

  • 客户端上传数据加密 A

    1. 客户端随机产生一个16位的字符串,用以之后AES加密的秘钥,AESKey。
    2. 使用RSA对AESKey进行公钥加密,RSAKey
    3. (此处某些重要的接口需要加签处理,后续讲解,不要加签处理的省略该步骤)
    4. 将明文的要上传的数据包(字典/Map)转为Json字符串,使用AESKey加密,得到JsonAESEncryptedData。
    5. 封装为{key : RSAKey, value : JsonAESEncryptedData}的字典上传服务器,服务器只需要通过key和value,然后解析,获取数据即可。
  • 服务器获取数据解密 B

    1. 获取到RSAKey后用服务器私钥解密,获取到AESKey
    2. 获取到JsonAESEncriptedData,使用AESKey解密,得到明文的客户端上传上来的数据。
    3. (如果客户端进行了加签处理,此处需要验签,以保证数据在网络传输过程中是否被篡改)
  • 服务器返回数据加密 C

    1. 将要返回给客户端的数据(字典/Map)转成Json字符串,用AESKey加密处理
    2. (此处也可以加签处理)
    3. 封装数据{data : value}的形式返回给客户端
  • 客户端获取数据解密 D

    1. 客户端获取到数据后通过key为data得到服务器返回的已经加密的数据AESEncryptedResponseData
    2. 对AESEncryptedResponseData使用AESKey进行解密,得到明文服务器返回的数据。

加签和验签

第二节——"客户端,服务端的通信逻辑"已经基本上把客户端和服务端的通信加密逻辑讲完了。至于"加签和验签"主要是针对数据传输过程中,防止数据被篡改的一种做法。

数据被篡改,栗子:

对于一个运动类型的APP,上传运动的步数,是一个常见的接口操作。比如该接口会有几个字段,step(步数),time(步数产生的时间),memberId(用户id)。

假设某用户抓取了你上传的数据包,然后成功的破解了你之前的加密方式。得到对应的明文,此时该用户就可以随意修改你的数据,比如step,然后以相同的方式加密,post到你的服务器,此时服务器会认为这是一次正常的请求,便接受了这个修改后的步数。其实此时的数据是错误的。如此神不知鬼不觉。。。

为了防止这种做法,我们可以是加签的处理方式

  • 加签处理(数据发起方都可以加签,此处是客户端)

    1. 我们一般取其中的关键字段(别人可能修改的字段),比如此时step,和time及memberId,都比较敏感。
    2. 在上文的A中的第二步之后,获取step,time,memberId,拼接成一个字符串(顺序和服务器约定好),然后使用md5加密,采用base64编码(编码格式和服务约定)。得到signData
    3. 然后将获取到的signData以key-value的形式保存到原来明文的数据包中,然后进行A的第三步
  • 验签处理(数据接受方都可以验签,此处服务端)

    1. 如上,到B的第三步,此时已经得到了客户端上传的明文数据
    2. 按照喝客户端约定的字段拼接,将得到的step,time,memberId拼接后,使用同样的md5_base64处理,然后比较数据包中的签名sign是否和客户端当时的签名一致。
    3. 如果一致,接受数据。不一致,抛弃数据,终止本次操作

假设加签之后的数据包被截获,然后解密成功,得到明文的数据包。但是签名md5加密是无法解密的(单向加密)。此时即时修改了step,然后post到服务器,服务器通过修改后的step,time,memberId得到的字符串经过md5加密后,一定会与客户端的签名不一致。从而数据被抛弃。

流程图描述上文

客户端服务端通信加密逻辑.png

示例代码

关于AES,和RSA加密解密,只能出iOS端的代码。关于如何在Linux下生成RSA公钥和私钥证书,参照RSA公钥、私钥生成,详细讲解,网上很多

github的demo地址--CAAdvancedTech

运行,如下入显示

首页选择加密模块 AES,RSA加密解密页面

RSA公钥-生成自签名证书

// 生成1024位私钥
openssl genrsa -out private_key.pem 1024

// 根据私钥生成CSR文件
openssl req -new -key private_key.pem -out rsaCertReq.csr

// 根据私钥和CSR文件生成crt文件
openssl x509 -req -days 3650 -in rsaCertReq.csr -signkey private_key.pem -out rsaCert.crt

// 为IOS端生成公钥der文件
openssl x509 -outform der -in rsaCert.crt -out public_key.der

// 将私钥导出为这p12文件
openssl pkcs12 -export -out private_key.p12 -inkey private_key.pem -in rsaCert.crt

参照 漫谈RSA非对称加密解密

推荐工具

  1. 关于画流程图

    之前一致比较苦扰在Mac上有哪一款好用的可以画流程图,UML的工具,甚至都考虑过Keynote。最后发现这款在线的工具很不错,上图就是使用这款工具,第一次画的。效果不错。就是导出png图片分辨率不是很好

    工具processOn

    Mac 上最好用的流程图软件是什么?

  2. 关于AES加密解密在线工具

    在线AES加解密


喜欢请随意


结合RSA,AES128,MD5---移动端与服务端在通信层的加密处理

相关文章

  • 结合RSA,AES128,MD5---移动端与服务端在通信层的加

    很高兴能在项目中使用到RSA,AES128,以及MD5,用以保证客户端(Client)和服务端(Server)之间...

  • 无标题文章

    Python服务端RSA 与 iOS RSA 等待编辑

  • Binder 笔记

    1IPC 概念: 序列化与binder两方面 android应用层来说是客服端与服务端通信的媒介,接口是服务端暴露...

  • HTTP协议学习笔记(2)

    客户端与服务端的通信与TCP连接 1. 客户端与服务端的通信过程 当客户端想要跟服务端进行信息交互时,过程如下: ...

  • Nginx websocket proxy断连问题

    由于项目中需要服务端向移动设备主动推送信令,于是引入websocket协议进行移动设备和服务端之间的通信。Demo...

  • iOS RSA+AES与后端交互流程

    1.服务端数据加密- iOS端把RSA的公钥传给服务端,服务端用AES进行数据加密,然后拿客户端的RSA公钥把AE...

  • 怎么查看移动app和server的通信?

    测试移动客户端的同学一定会涉及到客户端和服务端的通信,包括HTTP和TCP通信。查看具体的HTTP、TCP通信应该...

  • APP端与Server端通讯加解密 API设计

    APP端与服务器端如何安全的进行通讯,是后台设计开发中比较重要的问题,这里使用RSA公私钥,还有AES128,MD...

  • IOS JWT 解析。

    在移动端和服务端通信中,一般有两种认证方式:token 和 session。 1、session/cookie 认...

  • 移动端路由

    移动端路由层设计 什么是移动端路由层: 路由层的概念在服务端是指url请求的分层解析,将一个请求分发到对应的应用处...

网友评论

  • 谦言忘语:手动点赞。
    文章讲的很容易明白。方案也不错。学习了。
    我们目前的验签功能跟楼主讲的是一样的,首先md5已经足够安全了,基本只能靠暴力破解,而且一般我们会把时间戳加上,每个接口对需要验签的数据个数和顺序都可能不同,而且客户端会有一个加密的key加上去,还算是复杂了,破解的成本很高。这种方式做验签差不多了,觉的不够还可以对md5得出的数据再进行几次md5啊,哈哈,让你破解。不过如果被人知道验签的数据和方式,依旧得跪啊。唉,真是没有完全安全的加密方式。
    mdiep:谢谢,是的,当被破解任知道验签的数据和方式之后,自然容易被破解,那么我认为这可能是自己人才能办得到。我们所做的一切都是在不断的提高破解成本。毕竟,整套加密流程如果算是一个正向过程,那么一定存在一套逆向流程可以破解。我想是这样的:joy:,还要多去学习
  • 任重而道元:楼主,我使用的是SpringBoot,如何在后台操作呢,给个思路吧。
  • BillBian:客户端传送到服务端用RSA和AES可以理解,因为服务端有私钥。服务端传送数据到客户端,怎么保证安全性?
    mdiep:@被风追的猪 666 是的。
    BillBian:@糊涂猫until 就是说服务端用之前客户端的请求时所用AES的key对将要返回的数据加密,然后客户端还是用之前在请求是的AES的key进行解密。这样因为之前对AES的key进行了RSA加密,所以就没有问题了。谢谢:smile:
    mdiep:@被风追的猪 其实,在上传给服务端数据之前,客户端的每一次接口请求,会生成一个随机的16位字符串,这个字符串作为AES的加密的Key。服务端在获取到数据后,进行逻辑处理后。将要返回给客户端的数据用之前的16位Key,加密数据。并返回给客户端。因为在一次通信过程中。这个随机的16位字符串Key是在内存中存在的,所以可以解密服务端返回数据。

    这样应该可以尽量保证数据安全。
  • C_HPY:我们因为返回数据没有做加密处理,前几天还被恶意修改客户端拿到的返回数据,造成了逻辑上的漏洞。数据安全确实是重中之重。
    mdiep:@C己__ 是的,必要的数据加密还是很重要的,不然用户使用后发现,就很难再次相信我们的产品
  • cqxxxxxxxx:学习
  • c6e84b67afce:有个问题请教下:在客户端与服务器通信的时候,AESKey是用服务端下发的RSA公钥(此处假设在客户端对服务端的单向验证通过前提下)来加密的,对于这个AESKey是只有服务端的RSA私钥才能解密获得的,即AESKey被破解的可能性应该是比较低的。
    问题点:
    1.即使通信被劫持,关键字段是使用AESKey加密过的;中间人修改关键字段,(就算忽略验签)服务端在使用AESKey解密过程也会失败,此时加签的意义何在?
    2.即使AESKey被泄露/破解,加签规则大多在于时间戳\乱序\等等,签名规则被破解的可能性也很大吧。
    3.在AESKey被破解的前提下,APP存在的意义也就呵呵了,通信内容完全被劫持,用户信息也就被泄露。
    4.在签名规则被破解的前提下,也无法保证AESKey的正确性,此时服务端对客户端的验证是不是就成为必不可少的条件?
    另:SSL/TLS协议在握手过程有三个随机数的概念,最后才生成一个master-key,但客户端只是生成16位随机字符串从而作为通信中的对称密钥?此处不是很了解,望指教~
  • 梧桐g110387:楼主,我用你的 demoRSA 解密的时候会蹦,怎么回事
  • w4lle:感谢分享
  • 拥抱月亮的大星星:MArk,以后肯定用到
    mdiep:嗯嗯
  • olni:不懂了解一下,写不错。囍
    mdiep:@olni thanks
  • 相互交流:楼主将要上传的数据,上传和服务器约定好,先用Md5加密,在用Base64加密,然后传输,你没有发现,截取数据过后,串改过后,他也用同样的方式进行加密,然后在上传服务器,你也不知道是不是一定没有串改。。
    相互交流: @糊涂猫until我并不想和你争论,我的意思是这种方式也不是安全的,不是企业也不需要去购买CA证书了。
    世外大帝:删了吧,楼主可能刚看加密这块,还有,md5严格意义上甚至都不能称之为加密,只是转码,和base64一样
    mdiep:@相互交流
    第一点:他要获得明文数据之前,他得要用RSA解密拿到AES的密钥,再利用密钥解密得到明文数据包。这个是前提
    第二点:md5在其中只是作为签名加密算法被使用,别人截获到我的数据,对于签名的规则,你可以和服务器约定的更为复杂一点,这样即使截取了你的数据,在不知道签名规则的前提下,即使知道md5签名加密算法,也无济于事。建议去看SSL原理。
  • 6f47b7f91386:为什么不直接全部用RSA?
    mdiep:@sandogeek 我的意思是相比于使用多种加密方式而言的。
    6f47b7f91386: @糊涂猫until get新姿势,不过为什么rsa被破解的可能性更大
    mdiep:主要是基于两点
    1. 仅仅用RSA,被破解的可能性更大,安全性上不一定满足要求
    2. RSA的速度比较慢,特别对于数据大的时候,而作为提交给服务端,数据量一般都比较大,做为加密和解密,双方都会消耗很大的性能。

    你可以尝试用RSA加密一个很长的字符串,得到的密文将是非常的长,这样带来的网络流量也会变大。
  • 云逸枫林:不错,流程很清晰,确实结合的很完美。而且工作量也尽量缩小了。不过有一点顾虑,签名和验签的地方,如果被劫持了修改了关键字段,感觉还是可以破解,不过在拼接顺序上需要麻烦点。多谢分享。
    mdiep:@bigCatloveFish 这个怎么说,如上这一套加密逻辑其实并不是很复杂,估计两天就可以搞定。
    bigCatloveFish:@糊涂猫until 关键问题是 成本和产出是不是成正比~
    mdiep:@云逸枫林 按照你的设想,是的,如果同时截获签名,并且掌握了生成签名的规则,确实可以破解。所以可以在签名规则上设置的复杂些,另外签名的算法可以不采用目前已经公开的算法,而客户端和服务器约定,自己写一套签名算法,这样相比较而言,想破解的难度又会更加困难……但终归一点,只要功夫深,还是可以被破解的,只是加密与解密两者间的博弈:yum:

本文标题:结合RSA,AES128,MD5---移动端与服务端在通信层的加

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