这篇文章将介绍iOS的签名机制，在此之前要先简单介绍下加密相关信息，顺便聊下https对http的加密流程

  • 对称加密
  • 非对称加密
  • Hash函数（单向散列函数）
  • iOS签名机制
  • https加密流程

信息加密从加密解密的角度划分话，可以分为对称加密、非对称加密以及hash函数。对称加密简单来说就是加密和解密的密钥是同一把；相对应的，非对称加密在加密解密过程使用的密钥是不同的；而hash函数是不可逆加密，即在加密的密文是不可解密的。下面将分别对这三种分类进行阐述。

1 对称加密

如上文所说，对称加密，即加密和解密过程使用的是同一个密钥，也称单密钥加密。
这种加密的算法主要有以下几种方式：

1.1 DES(Data Encryption Standard)加密

DES是一种将64bit明文输入块加密成64bit密文输出块的对称密码算法，使用的密钥长度也是64位，但实际使用的是56位（实际用到了56位，第8、16、24、32、40、48、56、64位是校验位， 使得每个密钥都有奇数个1）。具体可见此链接

1.2 3DES(Triple Data Encryption Algorithm)

3DES又称Triple DES，是DES加密算法的一种模式，它使用2条不同的56位的密钥对数据进行三次加密。具体可参见这里

1.3 AES(Advanced Encryption Standard)

取代DES成为新标准的一种对称密码算法，AES的密钥长度有128、192、256bit三种。具体可参见这里
这里只是对上面几种算法进行简单的描述，若想详细深入的了解，可以参阅其他资料，网上有很多相关资料。

1.4 对称密码的利弊

  • 由于加密解密使用的是同一个密钥，因此在解密的时效率很高。
  • 同样，由于加密解密使用的是同一个密钥，那么密钥被窃取的风险很高，在传输过程中一旦被窃取，那密文的加密就形同虚设。

为了避免密钥被窃取，可以通过以下几个方法进行避免：

  • 事先共享密钥，避免中途传输；
  • 通过密钥分配中心；
  • Diffie-Hellman密钥交换

2 非对称加密（公钥密码）

相对于对称加密，非对称加密在加密和解密的过程使用的密钥是不同的，区分开来是加密密钥和解密密钥。

  • 加密密钥，一般是公开的，因此该密钥称为公钥（public key）.
  • 解密密钥，由消息接收者自己保管的，不能公开，因此也称为私钥（private key）.
  • 公钥和私钥是一一对应的，是不能单独生成的，一对公钥和密钥统称为密钥对（key pair）.
  • 由公钥加密的密文，必须使用与该公钥对应的私钥才能解密.
  • 由私钥加密的密文，必须使用与该私钥对应的公钥才能解密

2.1 RSA

目前使用最广泛的公钥密码算法是RSA。
RSA的名字，由它的3位开发者，即Ron Rivest、Adi Shamir、Leonard Adleman的姓氏首字母组成。具体可参考这里

2.1.1 非对称加密密钥配送流程

  • 消息接受者生成一对公钥、私钥
  • 消息接受者将公钥传递给消息发送者
  • 消息发送者用接收者的公钥对消息进行加密，然后传递给消息接收者
  • 消息接收者通过用之前生成的私钥来对消息进行解密

2.1.2 缺点：

由于非对称加密解密，所以解密速度相对于对称加密算法来说效率比较慢。

2.2 混合密码

混合密码是将对称密码和公钥密码的优势相结合的方法

  • 解决了公钥密码速度慢的问题
  • 并通过公钥密码解决了对称密码的密钥配送问题

2.2.1 混合密码使用流程：

  • 1）消息接收者随机生成本次通信的临时密钥（加密用的公钥、解密用的私钥）
  • 2）消息接收者将生成的公钥传递给消息发送者
  • 3）消息发送者生成对称密钥，给消息进行加密生成密文，然后用消息接收者给的公钥给自己的密钥进行加密，生成密钥的密文
  • 4）消息发送者将加密后的消息和加密后的密钥一同发给消息接收者
  • 5）消息接收者用自己的公钥将消息发送者的密钥进行解密得到对称加密的密钥，然后用此密钥对消息密文进行解密获取消息内容

2.3 单向散列函数(One-way hash function)

单向散列函数，可以根据根据消息内容计算出散列值，散列值的长度和消息的长度无关，无论消息是1bit、10M、100G，单向散列函数都会计算出固定长度的散列值

单向散列函数，又被称为消息摘要函数（message digest function），哈希函数

输出的散列值，也被称为消息摘要（message digest）、指纹（fingerprint）

2.3.1 特点：

  • 1）根据任意长度的消息，计算出固定长度的散列值
  • 2）计算速度快，能快速计算出散列值
  • 3）消息不同，散列值也不同
  • 4）具备单向性，即根据散列值无法算出消息

2.3.2 当前算法有

  • MD4、MD5

产生128bit的散列值，MD就是Message Digest的缩写，目前已经不安全
Mac终端上默认可以使用md5命令
MD5算法因其普遍、稳定、快速的特点，仍广泛应用于普通数据的错误检查领域

  • SHA-1

产生160bit的散列值，目前已经不安全

  • SHA-2

SHA-256、SHA-384、SHA-512，散列值长度分别是256bit、384bit、512bit

  • SHA-3：Secure Hash Algorithm 3

全新的安全散列算法

2.3.3 单向散列算法的应用

  • 1）防止数据被篡改：通过散列值对比数据是否被篡改
  • 2）口令加密：通过散列值来验证输入的口令是否正确（同之前的对比）

前面介绍了主要的加密算法，当然都是简单介绍，如果想更深入的了解，可以查看其它资料。

下面将介绍一些将以上算法进行综合运用的复杂操作。

3 综合加密

3.1 数字签名

接收的消息是否完整
接收的消息有没有被篡改
消息发送者否认了此消息是其发送的
······
为解决以上的问题，数字签名出现了。
消息发送者通过数字签名，保证了此消息是其发送的，也保证了消息有没有被篡改。

数字签名包含两个部分，一个是生成签名，另一个是验证签名。
生成签名，由消息发送者完成，通过“签名密钥”生成
验证签名，由消息的接收者完成，通过“验证密钥”验证

以下是具体的实现步骤：

3.1.1 使用流程：

低效使用:

  • 1）消息发送者使用自己生成的密钥对中的私钥将消息进行加密来签名
  • 2）消息发送者将签名（加密后的消息）、消息发送给消息接收者
  • 3）消息接收者在收到消息后，用消息发送者的公钥将签名进行解密
  • 4）将解密后的消息与之前消息发送者发送过来的消息进行对比，两者一致则验证成功

这种方式是十分低效的，当消息内容比较大时，对消息进行加密签名，效率会明显下降。

改进

  • 消息发送者使用单向散列函数对消息生成散列值
  • 消息发送者使用自己的密钥将散列值进行加密签名
  • 消息发送者将消息和签名发送给消息接收者
  • 消息接收者对收到的消息进行散列函数计算生成散列值，用发送者的公钥对签名进行解密得到散列值
  • 拿自己生成的散列值和解密后的散列值，两者一致则验证成功

这里相比较上面一种方式，虽然多了对消息进行散列值生成操作，但是相比较对信息进行加密，对固定长度的散列值进行加密解密的效率要高很多，尤其是消息内容比较大时。

3.1.2 缺点

正确使用签名的前提是，验证签名的公钥必须属于真正的发送者，如果遭中间人攻击，公钥进行伪造，会导致数字签名失效
因此，在验证签名之前，首先验证公钥的合法性

3.2 证书

全称叫公钥证书（Public-key Certificate，PKC）

里面有姓名、邮箱等个人信息，以及此人的公钥，并由认证机构（Certificate Authority，CA）施加数字签名，CA就是能够认定“公钥确实属于此人”并能够生成数字签名的个人或者组织

3.2.1 操作步骤

  • 消息接受者生成密钥对，将公钥传给认证机构
  • 认证机构用自己的私钥进行数字签名并生成证书（接收者的公钥+认证机构的数字签名）
  • 消息发送者从认证机构获取数字签名后的证书，然后用认证机构的公钥验证数字签名，确认接收者的合法性
  • 验证过合法性后，用合法的公钥对消息进行加密，然后发给接收者
  • 消息接收者接到消息后用自己的私钥进行解密

以下是一张网上找的图片解说：

iOS签名机制 - 图1

3.3 iOS签名机制

保证安装到用户手机上的APP都是经过Apple官方允许的

3.3.1 操作流程

  • 生成mac设备的密钥对（用钥匙串的证书助理获取到certSigningRequest文件）
  • 从apple.develperment网站申请证书.cer（需要要上传certSigningRequest文件，就是要Apple用其私钥对mac公钥进行数字签名—>.cer证书文件）
  • 申请获得.mobileprovision文件（需要将上面的证书连同app id、devices、entitlements等信息一同用Apple私钥再进行加密签名—>.mobileprovision文件）
  • 开发者用mac私钥对app进行加密数字签名—>ipa安装包（APP、签名）
  • 用户获取安装包，用apple公钥验证.mobileproviesion文件，获取里面的权限、证书、devices等信息，再用Apple公钥验证证书的签名获取mac公钥
  • 用户用验证获取到的mac公钥验证app安装包的数字签名，成功安装应用包

以下是从网上找了图片资源，进行了形象说明：

iOS签名机制 - 图2

如果是从appstore上下载应用：

1）Apple后台对app进行签名（用Apple的私钥）

2）用户用设备上的Apple的公钥进行验证签名，验证通过则进行安装

3.4 HTTPS

3.4.1 应用到的加密算法有

  • 对称加密
  • 非对称加密
  • 散列值
  • 数字签名

3.4.2 加密流程

  • 客户端访问服务端，前题是https网络协议的地址；
  • 连接上服务端后，服务端返回证书给客户端（证书中包含了服务端密钥对中的公钥、颁发机构、证书期限等信息）（这里有数字签名、非对称加密（服务端是一对非对称密钥对））
  • 客户端接收到服务端的证书后，验证证书有效性（证书颁发机构、过期时间等信息）
  • 验证证书有效后，客户端会生成一个随机值（客户端的密钥对——-对称加密，加密解密用的都是这个）
  • 客户端用验证后的公钥（服务端在证书中的公钥）加密刚刚生成的随机值（客户端密钥），发送给服务端
  • 服务端收到客户端的加密后的密钥后，用自己的私钥将其解密，得到客户端的密钥
  • 服务端将要发送给客户端的信息用刚刚得到的密钥进行加密，发送给客户端
  • 客户端用自己的密钥（之前生成的随机值）将服务端返回的的加密信息进行解密

https相对于http的安全过程大致是以上这些信息，当然对于证书的验证等更细更深的信息还需要深入了解SSL和TLS等。以下再通过图片来解释下这个流程，图片来源于网络。

iOS签名机制 - 图3