iOS签名机制

如何选择加密算法

摘要算法默认就使用SHA1准没错。

首先从加密的类型区分,AES——对称加密;RSA——非对称加密。可以理解为,加密和解密公有一个秘钥的属于对称加密;加解密使用不同秘钥的属于非对称加密。非对称加密的出现是为了解决秘钥传输的问题,但相同秘钥长度的前提下,对称加密的强度要远远大于非对称加密的强度(毕竟两种加密算法设计时的目的就不相同)。

如果需要在设备与设备之间或者设备与服务端之间传输密文,可以考虑一下使用RSA,其他情况下不太建议使用RSA。RSA算法速度慢、没有AES强度大。

一、密码加密算法

根据密钥的使用方法,可以将密码分为2种

1.1. 对称密码

image.png

1.2. 公钥密码(非对称密码)

image.png

二、对称密码(Symmetric Cryptography)

在对称密码中,加密、解密时使用的是同一个密钥。常见的对称密码算法有:DES、3DES、AES。

2.1. DES(Data Encryption Standard)

DES是一种将64bit明文加密成64bit密文的对称密码算法,密钥长度是56bit。规格上来说,密钥长度是64bit,但每隔7bit会设置一个用于错误检查的bit,因此密钥长度实质上是56bit。

2.1.1. 劣势:

由于DES每次只能加密64bit的数据,遇到比较大的数据,需要对DES加密进行迭代(反复)。目前已经可以在短时间内被破解,所以不建议使用。

2.2. 3DES

3DES,将DES重复3次所得到的一种密码算法,也叫做3重DES。目前还被一些银行等机构使用,但处理速度不高,安全性逐渐暴露出问题。

2.2.1. 3个密钥都是不同的,也称为DES-EDE3

image.png

2.2.2. 如果密钥1、密钥3相同,密钥2不同,称为DES-EDE2

image.png

2.2.3. 如果所有密钥都使用同一个,则结果与普通的DES是等价的

image.png

2.3. AES(Advanced Encryption Standard)

取代DES成为新标准的一种对称密码算法,AES的密钥长度有128、192、256bit三种。

在2000年时选择Rijindael算法作为AES的实现,目前AES,已经逐步取代DES、3DES,成为首选的对称密码算法。

2.4. 密钥配送问题

在使用对称密码时,一定会遇到密钥配送问题。

假设,Alice将使用对称密码加密过的消息发给了Bob,只有将密钥发送给Bob,Bob才能完成解密,在发送密钥过程中,可能会被中间人窃取密钥,最后中间人也能完成解密。

三、公钥密码(Public-key Cryptography)

公钥密码中,密钥分为加密密钥、解密密钥2种,它们并不是同一个密钥。公钥密码也被称为非对称密码(Asymmetric Cryptography)。

  • 加密密钥,一般是公开的,因此该密钥称为公钥(public key)

  • 解密密钥,由消息接收者自己保管的,不能公开,因此也称为私钥(private key)

  • 公钥和私钥是一 一对应的,是不能单独生成的,一对公钥和密钥统称为密钥对(key pair)

  • 由公钥加密的密文,必须使用与该公钥对应的私钥才能解密

  • 由私钥加密的密文,必须使用与该私钥对应的公钥才能解密

3.1. 解决密钥配送问题

由消息的接收者,生成一对公钥、私钥,将公钥发给消息的发送者,消息的发送者使用公钥加密消息。

3.2. 主要的公钥密码算法:RSA

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

3.3. 公钥密码的缺点

加密解密速度比较慢

四、混合密码系统(Hybrid Cryptosystem)

混合密码系统,是将对称密码和公钥密码的优势相结合的方法。解决了公钥密码速度慢的问题,并通过公钥密码解决了对称密码的密钥配送问题。网络上的密码通信所用的SSL/TLS都运用了混合密码系统。

4.1. 混合密码-加密

4.1.1. 会话密钥(session key)

为本次通信随机生成的临时密钥。作为对称密码的密钥,用于加密消息,提高速度。

4.1.2. 加密步骤(发送消息)

  • 首先,消息发送者要拥有消息接收者的公钥。

  • 生成会话密钥,作为对称密码的密钥,加密消息。

  • 用消息接收者的公钥,加密会话密钥

  • 将前2步生成的加密结果,一并发给消息接收者

4.1.3. 发送出去的内容包括

用会话密钥加密的消息(加密方法:对称密码)

用公钥加密的会话密钥(加密方法:公钥密码)

image.png

4.2. 混合密码-解密

4.2.1. 解密步骤(收到消息)

消息接收者用自己的私钥解密出会话密钥,再用解密出来的会话密钥,解密消息。

image.png

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

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

单向散列函数,又被称为消息摘要函数(message digest function),哈希函数。

输出的散列值,也被称为消息摘要(message digest)、指纹(fingerprint)。

5.1. 单向散列函数的特点:

1.根据任意长度的消息,计算出固定长度的散列值

2.计算速度快,能快速计算出散列值

3.消息不同,散列值也不同

4.具备单向性

5.2. 常见的几种单向散列函数:

5.2.1. MD4、MD5

产生128bit的散列值,MD就是Message Digest的缩写,目前已经不安全。Mac终端上默认可以使用md5命令。

5.2.2. SHA-1

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

5.2.3. SHA-2

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

5.2.4. SHA-3

全新标准

image.png

5.3. 单向散列函数的应用:

1.防止数据被篡改

2.口令加密

image.png

六、数字签名

可以确定收到的消息的真实性,防止数据被篡改、伪装、否认。

在数字签名技术中,有以下2种行为:

1.生成签名:由消息的发送者完成,通过“签名密钥”生成。

2.验证签名:由消息的接收者完成,通过“验证密钥”验证。

6.1. 思考

如何能保证这个签名是消息发送者自己签的?(用消息发送者的私钥进行签名)

6.2. 数字签名和公钥密码

数字签名,其实就是将公钥密码反过来使用

image.png

6.3. 数字签名的过程

image.png

6.4. 数字签名的过程 – 改进

image.png

6.5. 数字签名的作用

数字签名的作用不是为了保证机密性,仅仅是为了能够识别内容有没有被篡改。

1.确认消息的完整性

2.识别消息是否被篡改。如果有人篡改了文件内容或者签名内容,签名验证失败,证明内容会篡改。

3.防止消息发送人否认

6.6. 数字签名无法解决的问题

要正确使用签名,前提是用于验证签名的公钥必须属于真正的发送者。如果遭遇了中间人攻击,那么公钥将可以是被伪造的,数字签名将失效。所以在验证签名之前,首先得先验证公钥的合法性。

6.7. 如何验证公钥的合法性?证书

image.png

七、证书(Certificate)

密码学中的证书,全称叫公钥证书(Public-key Certificate,PKC)。里面有姓名、邮箱等个人信息,以及此人的公钥,并由认证机构(Certificate Authority,CA)施加数字签名。

CA就是能够认定“公钥确实属于此人”并能够生成数字签名的个人或者组织

  • 有国际性组织、政府设立的组织

  • 有通过提供认证服务来盈利的企业

  • 个人也可以成立认证机构

7.1. 证书的作用

可以确认公钥的合法性,以保证获取到的公钥是没有被别人篡改过的。

image.png

八、iOS签名机制

8.1. iOS签名机制的作用

保证安装到用户手机上的APP都是经过Apple官方允许的,不管是真机调试,还是发布APP,开发者都需要经过一系列复杂的步骤:

1.生成CertificateSigningRequest.certSigningRequest文件

2.获得ios_development.cer\ios_distribution.cer证书文件

3.注册device、添加App ID

4.获得*.mobileprovision文件

对于真机调试,现在的Xcode已经自动帮开发者做了以上操作

8.2. 思考

每一步的作用是什么?

.certSigningRequest、.cer、.mobileprovision文件究竟里面包含了什么?有何用处?

8.3. iOS签名机制 – 流程图

image.png

8.4. 生成Mac设备的公私钥

CertificateSigningRequest.certSigningRequest文件,就是Mac设备的公钥。

image.png

8.5. 获得证书

ios_development.cer、ios_distribution.cer文件

利用Apple后台的私钥,对Mac设备的公钥进行签名后的证书文件

image.png

8.6. 生成mobileprovision

image.png
image.png

8.7. 安全检测

image.png

8.8. AppStore

如果APP是从AppStore下载安装的,你会发现里面是没有mobileprovision文件的。

它的验证流程会简单很多,大概如下所示:

image.png

九、p12文件

让别人可以调试同一个App。也就是说别人也可以通过p12文件通过苹果的签名验证。

所以该文件里包含了当初你的Mac生成的私钥、公钥和证书等信息。

你可能感兴趣的:(iOS签名机制)