本文从Base64的原理,Base64在iOS端和Java端不同的编解码造成无法加解密的坑,AES的原理和一个完整的Demo.
希望看完本篇文章能让读者对客户端与后台的整体加密流程有更深的认识.因此本篇会写的比较详细.
Demo下载地址,欢迎大家的小星星
一: Base64原理
base64之所以称为base64,是因为其用64个字符对任意数据进行编码,标准base64的字符如下:
base64可以用来将binary的字节序列数据编码成ASCII字符序列构成的文本，使用时，在传输编码方式中指定base64。使用的字符包括大小写字母各26个，加上10个数字，和加号“+”，斜杠“/”，一共64个字符，等号“=”用来作为后缀用途。
完整的base64定义可见RFC 1421和RFC 2045。编码后的数据比原始数据略长，为原来的4/3.。在电子邮件中，根据RFC 822规定，每76个字符，还需要加上一个回车换行。可以估算编码后数据长度大约为原长的135.1%。( 如果源码为760个字符, 则编码后的长度为760 * (4 / 3) + 10(换行符) )
注意
当原数据长度不是3的整数倍时, 如果最后剩下一个输入数据，在编码结果后加2个“=”；如果最后剩下两个输入数据，编码结果后加1个“=”；如果没有剩下任何数据，就什么都不要加，这样才可以保证数据还原的正确性。
以 Hello!! 为例，其转换过程为：
Hello!! Base64编码的结果为 SGVsbG8hIQAA 。最后2个零值只是为了Base64编码而补充的，在原始字符中并没有对应的字符，那么Base64编码结果中的最后两个字符 AA 实际不带有效信息，所以需要特殊处理，以免解码错误。
标准Base64编码通常用 = 字符来替换最后的 A，即编码结果为 SGVsbG8hIQ==。因为 = 字符并不在Base64编码索引表中，其意义在于结束符号，在Base64解码时遇到 = 时即可知道一个Base64编码字符串结束。
根据上面的结论,可将base64分为如下的格式:
- CRLF 这个参数看起来比较眼熟，它就是Win风格的换行符，意思就是使用CRLF这一对作为一行的结尾而不是Unix风格的LF
- DEFAULT 这个参数是默认，使用默认的方法来加密
- NO_PADDING 这个参数是略去加密字符串最后的”=”
- NO_WRAP 这个参数意思是略去所有的换行符（设置后CRLF就没用了,将每76个字符串产生的换行符略去）
- URL_SAFE 这个参数意思是加密时不使用对URL和文件名有特殊意义的字符来作为加密字符,因为标准base64包含"+"和"/",因此不适合直接放在URL中传输.因为URL编译器会将"+","/"转换成XX%的样式.而这些"%"在录入数据库的时候还会进行转码,为了解决此问题可采用一种适用于URL的改进base64,它不在末位添加"=",将"+"转换成"-",将"/"转换成"_".
iOS在7.0之后虽然可以用原生API进行base64编解码
/* Create an NSData from a Base-64 encoded NSString using the given options. By default, returns nil when the input is not recognized as valid Base-64.
*/
- (nullable instancetype)initWithBase64EncodedString:(NSString *)base64String options:(NSDataBase64DecodingOptions)options NS_AVAILABLE(10_9, 7_0);
/* Create a Base-64 encoded NSString from the receiver's contents using the given options.
*/
- (NSString *)base64EncodedStringWithOptions:(NSDataBase64EncodingOptions)options NS_AVAILABLE(10_9, 7_0);
/* Create an NSData from a Base-64, UTF-8 encoded NSData. By default, returns nil when the input is not recognized as valid Base-64.
*/
- (nullable instancetype)initWithBase64EncodedData:(NSData *)base64Data options:(NSDataBase64DecodingOptions)options NS_AVAILABLE(10_9, 7_0);
/* Create a Base-64, UTF-8 encoded NSData from the receiver's contents using the given options.
*/
- (NSData *)base64EncodedDataWithOptions:(NSDataBase64EncodingOptions)options NS_AVAILABLE(10_9, 7_0);
可是当你信心满满准备用原生API进行编解码的时候,坑就来了
- 坑一:由于测试的字段比较短,base64生成的结果完全一样,你以为高枕无忧了.当字符串比较长的时候,NO_PADDING和有PADDING("="补位),生成的结果就完全不一样咯.
- 坑二:iOS这边可能是使用的NO_WRAP加密的, Java后台可以正常解密.可是反之就无法解出来.
- 坑三:
后台返回的base64编码字符串
这是后台返回的base64编码字符串,根据上面我所写的,这段字符串包含很多"-","_"字符串,说明后台采用的base64模式为URL_SAFE.
可是当时的我还傻乎乎的用苹果原生API解码这段字符串,可是解出的字符串永远无法用AES秘钥解密... ...
解决方法
其实解决方法真的就是一句话,跟你的后台人员好好沟通 好好沟通 好好沟通, 加解密的每一个流程都要好好沟通!
iOS原生API的有它自己的局限性, 所以我使用了base64的神器(GTMBase, 小伙伴可以在我demo中下载这个框架,这个框架满足了每一种的base64模式的编解码.)
因此为了两个平台的兼容,使用总结如下
GTMBase64 Padded YES != Java DEFAULT
GTMBase64 Padded NO == Java NO_PADDING | NO_WRAP
GTMBase64 Padded YES == Java NO_WRAP
GTMBase64 websafe Padded NO == java NO_PADDING | NO_WRAP | URL_SAFE
GTMBase64 websafe Padded YES == java NO_WRAP | URL_SAFE
总结: 因此使用过程中要用长数据进行测试,不要因为只成功测试一段短数据就确定成功了.用一位前辈的话来说:前面人踩过的雷,后面的人就不要好奇了.
二:AES加解密
根据上文的血泪史,请问当你做到AES加密的时候你第一件事会干什么?
当然就是和后台确定所用AES的密钥长度!!! AES-256是永远解不出AES-128加密的数据的.AES密钥长度分为128,196,256三种长度.我在项目中使用的为128位.
AES使用的是对称加密.所谓对称加密就是加解密双方使用的密钥相同.因此通过一种保密的方法让客户端与服务器拥有该密钥,即可成功使用加解密.
拿取AES密钥的流程
- 在客户端生成RSA密钥对,并将RSA公钥传给后台,私钥保存在客户端(关于RSA的知识点会在下一章详细介绍)
- 后台会将AES的密钥通过RSA公钥加密后传送到客户端,客户端在本地通过RSA私钥解密拿到AES密钥.
- 拿到AES密钥后就可以与后台完成加密数据传输了
使用AES传输数据的流程
(客户端加密流程)
- 将参数用AES密钥加密
- 将加密后的数据用base64编码发送给后台
(客户端解密流程) - 将后台返回的数据用已经与后台商量好的base64模式解码
- 讲解码后的数据用AES密钥解密,就可以拿到后台返回的json字符串,接下来转模型转字典都随你.
整个与Java后台交互的代码就放在demo中了,希望能对大家有所帮助
总结:
1.无论那种加密方式,自己一个人是搞不出来的,所以与后台的沟通很重要.
2.任何一种加解密方式都要在本地测试下,如果在本地都无法成功,那么就更别想与后台交互了.
参考链接:http://devm.cn/2015/08/25/base64-java-ios.html
http://www.jianshu.com/p/b8a5e1c770f9