2018-06-17

密码学探究

密码学是研究编制密码和破译密码的技术科学。密码是通信双方按约定的法则进行信息特殊变换的一种重要保密手段。依照这些法则，变明文为密文，称为加密变换；变密文为明文，称为脱密变换。密码在早期仅对文字或数码进行加、脱密变换，随着通信技术的发展，对语音、图像、数据等都可实施加、脱密变换

在iOS环境中，粗略介绍几种编码格式、摘要算法和加密规则

一.base64编码(可解码)

base64可以反编译，一般需要加密的信息不会使用base64编码,因为编码算法完全公开，很容易就会被破解。到是一些诸如用户名这种不需要加密但是可能也并不想被一眼看出来的信息，可以使用base64进行编码

base64 要求把每三个8Bit 的字节转换为四个6Bit 的字节，然后6Bit的两个高位置0 ，组成四个8Bit 的字节，转换后的字符串理论上将要比原来的长1/3

编码后的数据是一个字符串，其中包含的字符为：A-Z、a-z、0-9、+、/, 共64个字符：26 + 26 + 10 + 1 + 1 = 64

其实是65个字符，“=”是填充字符，用来表示添加的零值字节数，因为如果数据的字节数不是3的倍数，则其位数就不是6的倍数，那么就不能精确地划分成6位的块，此时，需在原数据后面添加1个或2个零值字节，使其字节数是3的倍数

二. 哈希(散列函数)(不可反算)

MD5
SHA1、HMAC_SHA1
SHA256(512)、HMAC_SHA256(512)

散列函数其实是一种信息摘要算法，并不是加密算法。它有一些独特的特性

MD5特点:

压缩性 : 任意长度的数据,算出的MD5值长度都是固定的(32位)
容易计算 : 从原数据计算出MD5值很容易
抗修改性 : 对原数据进行任何改动，哪怕只修改一个字节，所得到的MD5值都有很大区别(信息摘要)
强抗碰撞 : 想找到两个不同数据，使他们具有相同的MD5值(即伪造数据)，是非常困难的

但是正是因为同一条数据算出的MD5的值是固定的，所以如果把已知的词条和对应词条的HASH值收集起来，从而就可以进行查询得到。网上有一套数据库http://cmd5.com可以根据密文查到许多MD5的词条

正因为直接一个字符串进行MD5很容易被破解，所以有了一个改进方法：加盐

加盐（Salt）：这个盐是一个写在本地的固定字符串，拼接在明文的固定位置，然后再对拼接后的字符串进行MD5,这样就极大增加了破解的难度，即便被破解了，得到的字符串也是加盐后的字符串，无法拿到原始数据。但是，现在http://cmd5.com这个网站针对MD5做了各种各样的破解，各种加盐、对盐做MD5等等。再加上这个盐是写在本地的，一旦被泄露就不得不更换，而更换后就会对老版本产生影响，所以加盐这种做法现在也并不常用

HMAC : 另一个加密算法HMAC现在被广泛使用，HMAC运算利用哈希算法，以一个密钥和一个消息为输入，生成一个消息摘要作为输出,有HMAC_SHA1、HMAC_SHA256、HMAC_SHA512等算法，与SHA1、SHA256、SHA512等算法相比，HMAC需要一个密钥,而非HMAC不需要

HMAC是使用一个密钥加密，做两次散列，而这个密钥从服务器获取。诸如在做登录操作前，注册账号的的时候，服务器会根据账号随机生成一个密钥，和账号对应，并把密钥返还给客户端，客户端把密钥保存在本地(KeyChain)。而在输入密码后则对密码使用密钥做了一次HMAC的加密传给服务器，服务器则保存的是一个加密后的字符串。如果选择记住密码重新登录你会发现密码长度可能和真实密码长度并不一致，其实这只是个占位符而已

如果，换了一台设备，本地自然没有密钥，这样在登录的时候需要先返回这个账号对应的密钥，然后用密钥对账号做HMAC的加密传给服务器,这中间多了一部向服务器获取密钥的过程，有些APP换了设备第一次登录的时候有些慢，原因正是如此

如果随便换一台设备就可以根据账号向服务器获取密钥，那在知道账号的情况下，就可以获取到相应的密钥了，这并不安全，于是就有了设备锁。当换了一台设备的时候，服务器并不会马上返回密钥，而是会询问之前的设备，是否同意返回密钥，同意之后才会返回，QQ设备锁逻辑正是如此

还有一种危险的情况，黑客可能不需要知道你的密钥和密码，她只需要知道你的账号，并且截取你的密码加密后传输的字符串，就可以模拟你的登陆过程。之前是使用(密码.HMAC).md5这种方式，为了更安全起见，这时候需要加一个时间标识，这个时间标识可以从服务器获取，注意，这不是时间戳，只具体到分钟，比如20180623，现在就变成了(密码.HMAC+时间标识).md5，将这个字符串传给服务器，服务器会根据当前时间以同样的算法进行比对，因为可能时间分钟之间出现临界点或者超时之类的，在根据当前时间比对不成功时会以前一分钟为时间标识再比对一次，如果成功则算登陆成功，如果还不成功则登录失败，这给请求添加了时效性。理论上即便如此黑客也依然可以模拟登陆过程，这只是加大了破解的难度，归根结底，这也是一个双方博弈的过程

iOS7.0.3之后，可以使用钥匙串(KeyChain:AES加密)记住密码,保存的其实是加密后的字符串。以前有不少App都有找回密码的功能，这其实是因为服务端记住了用户的明文密码，不敢细想。而现在几乎没有App还保留这个功能，找回密码基本都是重新设置

iPhone5S开始推出了指纹识别，iOS8.0之后🍎允许App使用Touch ID进行验证, 但是部分场景必须进行密码校验

开机/重启
超过 48 小时未解锁设备
设备收到了远程锁定命令
五次未能成功匹配指纹
进入Touch ID设置模块或更新指纹

那指纹识别能够代替密码吗？必然不行，因为密码和指纹验证本身代表的意义就不同密码正确，用来证明是这个账号的主人指纹正确，用来证明是这个手机的主人

除此之外，使用哈希算法，也还有其他用途

版权维护

比如有张原创作品（origin.png）

打开后我重新截图（pirate），外观上没有任何变化，观察他们的md5值

可以发现，截屏后的md5值完全不一样，即便改成相同的名称也完全不一样。事实上是对二进制数据进行md5值，截屏后已经是完全不同的二进制文件,自然如果压缩了该文件，md5值自然也会随之改变。值得注意的是，直接复制其实就是复制二进制文件，md5值不会改变，单纯改变文件格式md5值也依然不会改变

云盘文件上传

文件上传时可以注意到，如果云盘上已经有了该文件，你会发现文件秒传成功。原因是什么呢？是因为服务器上查询到有相同的md5值与该文件的md5值相同，则默认云盘上已经有了该文件

还有，云盘上经常会封杀一些小视频(少儿不宜)，是根据什么来和谐的呢？自然也是根绝md5的值来判断。会有专门的鉴别人员，对一些视频做出鉴别后确认这些视频需要和谐掉，并且记录这些视频的md5的值，那么云盘上但凡md5值相同的都会被和谐掉

最重要的来了，如何逃避封杀呢

上面提到修改文件格式并不会改变md5值,但是压缩可以，所以可以把视频压缩后再上传还可以，将视频进行base64编码后再上传，因为可以解码，所以下载下来再进行解码即可恢复文件

三.对称加密算法(传统加密算法)

DES
3DES
AES(高级密码标准，美国国家安全局使用)

对称加密算法是使用密钥把明文加密变成密文，对密文解密变成明文，使用的是同一个密钥

DES：现在使用的已非常少，因为强度不够

3DES：使用的也非常少，因为密钥的保密非常重要，而这种算法却使用了3个密钥进行加密

AES：目前使用最多，加密强度也非常大，自然非常难破解

对称加密算法有两种加密方式：ECB(电子代码本)和CBC(密码块链)

ECB:把一个数据拆分成若干个数据包，对每一个数据进行独立加密然后再进行拼接

CBC:使用一个密钥和一个初始化向量(IV)对数据进行加密，也是把数据拆分成若干数据块，对每一块数据加密都要依赖上一个数据块，这可以保证数据的完整性

也就是说如果一块数据只修改了其中的一小部分，如果使用ECB加密，那密文相对于原先的密文就只有修改的这部分会改变，如果使用的CBC加密，则从当前数据块开始之后的所有数据的密文都会改变

加密解密用的是同一个函数CCCrypt,而这个函数有11个参数

/**
  *  @param kCCEncrypt     加密/解密
  *  @param self.algorithm 加密算法
  *  @param option         CBC/ECB
  *  @param cKey           加密密钥
  *  @param self.keySize   密钥长度
  *  @param cIv            iv初始化向量
  *  @param bytes]         加密的数据
  *  @param length]        加密的数据长度
  *  @param buffer         密文的缓冲区
  *  @param bufferSize     缓冲区的大小
  *  @param encryptedSize  加密结果的大小
  */
 CCCryptorStatus cryptStatus = CCCrypt(kCCEncrypt,
                                       self.algorithm,
                                       option,
                                       cKey,
                                       self.keySize,
                                       cIv,
                                       [data bytes],
                                       [data length],
                                       buffer,
                                       bufferSize,
                                       &encryptedSize);