转载

App安全之网络传输安全

移动端App安全如果按CS结构来划分的话,主要涉及客户端本身数据安全,Client到Server网络传输的安全,客户端本身安全又包括代码安全和数据存储安全。所以当我们谈论App安全问题的时候一般来说在以下三类范畴当中。

  • App代码安全,包括代码混淆,加密或者app加壳。
  • App数据存储安全,主要指在磁盘做数据持久化的时候所做的加密。
  • App网络传输安全,指对数据从客户端传输到Server中间过程的加密,防止网络世界当中其他节点对数据的窃听。

这一篇我们先聊下网络传输的安全。

安全相关的基础概念

网络安全相关的概念非常之多,要在广度和深度上都有所造诣很困难。但如果只是站在保障App通信基本安全这个维度上,做到合理使用安全算法,比大部分人所预期的都要简单很多。以下这些基础概念是必备知识:

  • 对称加密算法,代表算法AES
  • 非对称加密算法,代表算法RSA,ECC
  • 电子签名,用于确认消息发送方的身份
  • 消息摘要生成算法,MD5,SHA,用于检测消息是否被第三方修改过

怎么样算安全?

安全问题说白了是信任问题,谈到信任一定要有一个可被信任的实体。假设某天A收到了一条“Message”,如果这个消息确实是来自B,消息就可以被信任,那么B就这安全问题当中可被信任的实体。

对于A来说只要满足三点就说明收到“Message”是安全的:

  • Message有B的电子签名,表明消息确实是来自B。
  • Message没有被篡改过。
  • Message被某种加密算法加密过,只有A和B知道如何解密。

A和B的交谈如果放到网络世界当中,就是典型的Client-Server模式。和现实世界当中聊天不同的是,A和B所说的任何话都可以轻而易举的被其他人听到,隔墙随处有耳。

怎么去保证App网络传输的安全?

为了保证传输数据的安全,需要使用加密算法。在决定什么样的业务场景使用什么样的加密算法之前,先要了解我们的工具箱里有哪些可用工具。加密算法的工具箱里其实就两种工具:“对称”加密算法和“非对称”加密算法。清楚这两个分类是合理设计加密算法使用场景的大前提,两个分类里我们各挑选一个代表算法来研究,“对称”加密挑选AES,“非对称”加密选择RSA。了解AES和RSA之后我们再针对一些特定业务场景设计安全模型。

对称加密之AES

要深入了解像AES这种加密算法,对大部分初学的同学来说可能有些费时费力,但对算法掌握可以是个循序渐进的过程。由简至繁可以分为以下几个阶段:

阶段一:在AES诞生之前(1975年之前),早起的加密算法十分简单,是一种类似“暗号”的机制。通信的双方通过事先约定一种“加密机制”对明文进行处理,只要“加密机制”不被泄漏,信息就算安全。后来无数的经验表明算法总是会被第三方得知,对算法本身进行保密管理也不方便。

阶段二:到上世纪70年代,公众和政府意识到加密算法的重要性,由美国政府机构NBS牵头组织业界专家设计了DES算法。DES算法本身公开,但算法的安全全依赖于一个密钥。后来DES统治加密算法长达二十多年。不过DES从诞生到逐步退出历史舞台,一直都伴随着阴谋的论调。DES原本是由IBM提出,针对已有算法Lucifer改造而成,但DES制定的过程一直都有美国另一政府机构NSA的影子。

DES的两大特点是短密钥(short key)和结构复杂的s-box。有研究表明,是NSA当时劝说IMB短密钥足够安全,而且NSA也直接参与了s-box的设计。后来就一直有传言说NSA似乎有办法能轻易破解DES加密后的秘文。

到1990年,剧情出现反转。第三方独立研究者Eli Biham和Adi Shamir发布了破解块加密方式的通用破解方法differential cryptanalysis。出人意料的是按照NSA建议设计的s-box对这种破解方法有更好的免疫性,NSA的参与似乎更加提高了DES的安全性。

到1994年,剧情进一步升华。公开文件披露,早在1974年IBM的研究者就已经发现了differential cryptanalysis这种破解方式,不过这项研究被NSA禁止公开,理由是会威胁到国家安全,对,就是现在美剧里经常提到的national security。不仅如此,NSA还针对DES做了一些改造加强安全性。至此,NSA已经全身都挂满了节操,被业界质疑忍辱负重二十多年一声没吭,比24小时男主角Jack Bauer形象更加高大光辉。

阶段三:后来陆陆续续有一些针对DES破解的攻防战,DES最终演化成Triple DES的形态,不过在性能上已经出现明显问题,催生了今天对称加密的王者算法AES。AES在安全性,实现难度,运算性能上都有更好的表现。在全面了解AES之前,首先明确下好的加密算法必须符合哪些条件,这些条件是经过数十年加密破解攻防战所总结出来的。

  • 条件一,Confusion。对原文以最小的粒度(按字节)进行混淆生成秘文。最简单的confusion可以是A+3=D.
  • 条件二,Deffusion。对原文所包含的位置信息进行打乱排布,比如将第一个字节与第四个字节的位置对换.
  • 条件三,Secret Key。最终的秘文与Secret Key相关,只要持有Secret Key就可以对数据解密,将安全性的管理归于一个密钥的管理。

AES也是属于Cipher Block的一种,对于数据的加密都是已block为单位进行处理。针对需要加密的数据AES会先把数据分成一个个的block,每个block为16字节,可以排布成4x4的表格(又名矩阵:scream:)。如下图所示:

App安全之网络传输安全

如果最后一块不足16字节,用0补齐(padding)。后续的加密行为都是以block为单位进行处理,这个处理过程必须满足上述所说三个条件。加密的流程如下图:

App安全之网络传输安全

每一个block都会被单独依次处理,橙色方框表示加密的过程,这个过程包括两个方面,一方面是block本身数据的运算处理,二是与round key(也就是我们所说的对称加密算法密钥)进行运算处理。流程示意图如下:

App安全之网络传输安全

每一个block会依次经过Confusion(条件一),Difussion(条件二),Mix Data(可以看作再一次的Confusion)。最后一步是和我们的round key进行位运算得到最后的block秘文,这样一个完整的来回称为一个round,重复10次round就完成了block加密,当然每个round当中所使用的round key也会发生变化,以保证每次block加密所使用的key都不同。

针对每个block都重复上述处理过程就完成了AES加密过程,是不是so easy。当然这是被我高度抽象简化后的流程示意图,当中每一步都有很多的细节可以深入。密钥越长,每个block处理的round次数越多,AES就越安全,不过安全性和计算性能不可兼得,一般来说,我们使用128bit的Key就可以保证算法的安全性了。对了,解密的过程就是把上面加密的过程反过来做一遍。。

阶段四:明白了AES的流程,还需要了解正确的使用姿势。AES有两个经典的使用姿势,ECB模式和CBC模式。ECB模式可以用下图表示:

App安全之网络传输安全

ECB模式很简单,就是针对每一个block单独进行AES运算,每个block的处理结果之间没有任何关系。使用这种方式单个block都是安全的,但对包含大量block的数据来说,没有能够隐藏data pattern,因为相同的原文会产生相同的秘文,这对图片文件来说比较致命:

App安全之网络传输安全

相同的色块产生相同的秘文,这样相同颜色在图片当中出现的规律就和原始数据一样一目了然。

CBC模式针对ECB模式的缺陷做了处理,使得每个block的AES运算结果都依赖于之前的block秘文。如下图所示:

App安全之网络传输安全

每一个block在加密之前都会与上个block产生的秘文进行抑或运算,这样相同的数据也会产生不同的秘文,data pattern得以隐藏。第一个block没有刻可以或处理的秘文,就传入一个IV(初始化向量)。很明显,IV不同,AES运算的结果也不同。

非对称加密之RSA

RSA的使用已经相当广泛,也有很多优秀的教程解释其原理,推荐 其中一篇 。

关于RSA这种非对称加密算法,在App的使用当中,需要明白其主要作用有2个:

  • 信息加密: 通信双方可以在公开的网络环境下,“安全”的商量对称加密算法所使用的密钥。
  • 电子签名: 为了防止中间人攻击,通信双方在商量密钥之前可以通过签名算法确认对方的身份。

非对称加密算法本身是一种加密算法,但由于RSA本身加解密的性能在现在的计算机硬件条件下存在一定瓶颈,同时对加密数据的“安全长度”也有限制,被加密数据的长度一般要求不超过公钥的长度。所以RSA更多的是被用来商量一个密钥,如果密钥是安全的,那么后续的通信都可以使用上面提到的AES来完成,AES在性能上不存在瓶颈。

RSA算法最经典也是最广泛的应用场景是HTTPS,HTTPS的安全握手流程完整的阐释了“加密”和“签名”这两个概念。推荐 一篇文章 详细的分析HTTPS的握手流程。

RSA有另一个竞争者ECC,ECC现在使用也越来越广泛。二者在安全性上都不存在问题。不过ECC有一个优势,公钥私钥的生成速度快于RSA,在需要大量生产密钥对的业务场景下ECC会是更好的选择。RSA由于实现简单,出现较早,可以预见在很长一段时间内都将和ECC共存。

App网络安全实战

在App安全上的投入再多也不会过,不过安全问题上所投入的开发资源应该根据开发团队技术积累,产品发布deadline,用户规模及产品关注度等综合因素考量。结合这些因素我把App分为三类,各类App对安全级别的要求不同,投入产出也不同。

第一类,作坊式创业App

第二类,正规军App

第三类,带节操正规军App

原文  http://mrpeak.cn/blog/encrypt/
正文到此结束
Loading...