iOS的签名机制(一)
学习路线
- 加密解密
- 对称密码(DES、3DES、AES)
- 公钥密码(RSA)
- 单向散列函数
- MD4、MD5
- SHA-1、SHA-2、SHA-3
- 数字签名
- 证书
- iOS签名机制
加密解密
基础知识
- 常见英文
- encrypt:加密
- decrypt:解密
- plaintext:明文
- ciphertext:密文
- 密码的类型
- 根据密钥的使用方法,可以将密码分为2种
- 对称密码
- 公钥密码(非对称密码)
- 如下图:
- 根据密钥的使用方法,可以将密码分为2种
对称密码(Symmetric Cryptography)
- 在对称密码中,加密、解密时使用的是同一个密钥
- 常见的对称密码算法有
- DES
- 3DES
- AES
DES(Data Encryption Standard)
- DES是一种将64bit明文加密成64bit密文的对称密码算法,密钥长度是56bit
- 规格上来说,密钥长度是64bit,但每隔7bit会设置一个用于错误检查的bit,因此密钥长度实质上是56bit
- 由于DES每次只能加密64bit的数据,遇到比较大的数据,需要对DES加密进行迭代(反复)
- 就是把数据分组进行加密
- 目前已经可以在短时间内被破解,所以不建议使用
3DES
- 3DES,将DES重复3次所得到的一种密码算法,也叫做3重DES
- 目前还被一些银行等机构使用,但处理速度不高,安全性逐渐暴露出问题
- DES-EDE3
- 3个密钥都是不同的,也称为DES-EDE3
- 3个密钥都是不同的,也称为DES-EDE3
- 如果密钥1、密钥3相同,密钥2不同,称为DES-EDE2
- 如果所有密钥都使用同一个,则结果与普通的DES是等价的
AES(Advanced Encryption Standard)
- 取代DES成为新标准的一种对称密码算法
- AES的密钥长度有128、192、256bit三种
- 在2000年时选择Rijindael算法作为AES的实现
- 目前AES,已经逐步取代DES、3DES,成为首选的对称密码算法
- 一般来说,我们也不应该去使用任何自制的密码算法,而是应该使用AES,它经过了全世界密码学家所进行的高品质验证工作
密钥配送
- 密钥配送问题
- 在使用对称密码时,一定会遇到密钥配送问题
- 假设,Alice将使用对称密码加密过的消息发给了Bob
- 只有将密钥发送给Bob,Bob才能完成解密
- 在发送密钥过程中,可能会被Eve窃取密钥,最后Eve也能完成解密
- 如何解决密钥配送问题
- 事先共享密钥
- 密钥分配中心
- Diffie-Hellman密钥交换
- 公钥密码(非对称密码)
公钥密码(Public-key Cryptography)
- 公钥密码中,密钥分为加密密钥、解密密钥2种,它们并不是同一个密钥
- 公钥密码也被称为非对称密码(Asymmetric Cryptography)
- 在公钥密码中
- 加密密钥,一般是公开的,因此该密钥称为公钥(public key)
- 比如任何人都可以通过这个公钥加密发消息给我
- 解密密钥,由消息接收者自己保管的,不能公开,因此也称为私钥(private key)
- 公钥和私钥是一 一对应的,是不能单独生成的,一对公钥和密钥统称为密钥对(key pair)
- 由公钥加密的密文,必须使用与该公钥对应的私钥才能解密
- 由私钥加密的密文,必须使用与该私钥对应的公钥才能解密
- 加密密钥,一般是公开的,因此该密钥称为公钥(public key)
- 解决密钥配送问题
- 由消息的接收者,生成一对公钥、私钥
- 将公钥发给消息的发送者
-
消息的发送者使用公钥加密消息
- 为何叫公钥密码呢?
- 因为用于加密的钥匙是公开的
RSA
- 目前使用最广泛的公钥密码算法是RSA
- RSA的名字,由它的3位开发者,即Ron Rivest、Adi Shamir、Leonard Adleman的姓氏首字母组成
- 市场上常见的公钥密码有:RSA、ECC,ECC是目前最严密的非对称加密。
混合密码系统(Hybrid Cryptosystem)
- 对称密码的缺点
- 不能很好地解决密钥配送问题
- 公钥密码的缺点
- 加密解密速度比较慢
- 混合密码系统,是将对称密码和公钥密码的优势相结合的方法
- 解决了公钥密码速度慢的问题
- 并通过公钥密码解决了对称密码的密钥配送问题
- 网络上的密码通信所用的SSL/TLS都运用了混合密码系统
混合密码-加密
- 会话密钥(session key)
- 为本次通信随机生成的临时密钥
- 作为对称密码的密钥,用于加密消息,提高速度
- 加密步骤(发送消息)
- 首先,消息发送者要拥有消息接收者的公钥
- 生成会话密钥,作为对称密码的密钥,加密消息
- 用消息接收者的公钥,加密会话密钥
- 将前2步生成的加密结果,一并发给消息接收者
- 发送出去的内容包括
- 用会话密钥加密的消息(加密方法:对称密码)
- 用公钥加密的会话密钥(加密方法:公钥密码)
混合密码-解密
- 解密步骤(收到消息)
- 消息接收者用自己的私钥解密出会话密钥
- 再用第1步解密出来的会话密钥,解密消息
混合密码-加密解密流程
- Alice »»> Bob
- 发送过程,加密过程
- Bob先生成一对公钥、私钥
- Bob把公钥共享给Alice
- Alice随机生成一个会话密钥(临时密钥)
- Alice用会话密钥加密需要发送的消息(使用的是对称密码加密)
- Alice用Bob的公钥加密会话密钥(使用的是公钥密码加密,也就是非对称密码加密)
- Alice把第4、5步的加密结果,一并发送给Bob
- 接收过程,解密过程
- Bob利用自己的私钥解密会话密钥(使用的是公钥密码解密,也就是非对称密码解密)
- Bob利用会话密钥解密发送过来的消息(使用的是对称密码解密)
单向散列函数(One-way hash function)
- 单向散列函数,可以根据根据消息内容计算出散列值
- 散列值的长度和消息的长度无关,无论消息是1bit、10M、100G,单向散列函数都会计算出固定长度的散列值
单向散列函数的特点
- 根据任意长度的消息,计算出固定长度的散列值
- 计算速度快,能快速计算出散列值
- 消息不同,散列值也不同
- 具备单向性,不可逆的
单向散列函数
- 单向散列函数,又被称为消息摘要函数(message digest function),哈希函数
- 输出的散列值,也被称为消息摘要(message digest)、指纹(fingerprint)
- 常见的几种单向散列函数
- MD4、MD5
- 产生128bit的散列值,MD就是Message Digest的缩写,目前已经不安全
- Mac终端上默认可以使用md5命令
- SHA-1
- 产生160bit的散列值,目前已经不安全
- SHA-2
- SHA-256、SHA-384、SHA-512,散列值长度分别是256bit、384bit、512bit
- SHA-3
- 全新标准
- MD4、MD5
单向散列函数的应用
-
如何防止数据被篡改? 下面是没做防止篡改跟做防止篡改之后的图
- 单向散列函数的应用 – 防止数据被篡改
- 从1中可以看出,如果我要防止被篡改,我每次必须要拷贝一下放到安全的地方,但是如果我的源文件非常大,那就太麻烦了
- 那么就可以使用单向散列函数来解决
- 有一种常见的场景,我们在下载一些软件的时候,附带的有散列值(比如MD5值),防止我们下载完后,丢失数据不完整。我们下载完后,使用相同的单向散列函数,生成散列值,与附件中的对比一下,就能检查软件下载的完整性。
- 单向散列函数的应用 – 口令加密
- 口令加密即登录密码的加密
- 流程分析
- 注册流程
- 用户输入账户、密码
- 通过单向散列函数生成散列值(加密)
- 将加密后的数据传送给服务器
- 服务存储加密后的密码
- 登录
- 前三步跟上面一样
- 服务器拿到加密后的登录密码,与服务器之前储存的加密后的密码比对
- 一致则登录成功,反之失败
- 好处
- 即使中途有人获取到加密后的散列值或者公司服务的数据库被黑掉了,也没有用
- 因为他拿到这个加密后的散列值作为密码输入,然后登录,那么这个过程会将加密后的散列值再次加密,因此必然是错误的。
- 并且我们会发现,市场上所有的APP忘记密码都是不可能找回你原来的密码的,因为他也不知道你的密码是什么数据库里面都是散列值,只能让你重置密码。
- 反之一个平台可以找回用户原来的密码,那说明这个平台不安全。
- 注册流程
- 口令加密即登录密码的加密
数字签名
-
场景设置
- Alice发的内容有可能是被篡改的,或者有人伪装成Alice发消息,或者就是Alice发的,但她可以否认
- 问题来了:Bob如何确定这段消息的真实性?如何识别篡改、伪装、否认?
- 解决方案
- 数字签名
- 数字签名
- 在数字签名技术中,有以下2种行为
- 生成签名
- 由消息的发送者完成,通过签名密钥生成
- 验证签名
- 由消息的接收者完成,通过验证密钥验证
- 生成签名
- 问题:
- 如何能保证这个签名是消息发送者自己签的?
- 如果使用公钥密码
- 在公钥密码中,任何人都可以使用公钥进行加密
- 由于公钥是开放的,任何人都可以使用,那么就出现一问题,任何一个人只要拿到Alice的公钥,就能冒充他发消息
- Bob使用私钥解密消息内容,此时并不能确定是否一定是Alice本人发送的
- 如果将公钥密码反过来呢?
- 由消息的发送者生成公钥、私钥,并且公钥公开
- 用消息发送者的私钥进行消息签名
- 消息接收者用消息发送的公开的公钥进行验签名
- 那么这个问题就解决了
- 在数字签名中,任何人都可以使用公钥验证签名
- 如果使用公钥密码
- 由此可见,数字签名与公钥密码区别:
- 公钥密码
- 消息接收者生成公钥、私钥,并且将公钥公开,消息发送者用公钥加密,消息接收者用私钥解密。
- 数字签名
- 消息发送者生成公钥、私钥,并且将公钥公开,消息发送者用私钥加密,消息接收者用公钥解密。
- 公钥密码
- 如何能保证这个签名是消息发送者自己签的?
- 在数字签名技术中,有以下2种行为
- 数字签名和公钥密码
- 数字签名,其实就是将公钥密码反过来使用
- 数字签名,其实就是将公钥密码反过来使用
- 数字签名的过程
- 数字签名的过程 – 改进
- 上面那个流程还是有一些问题的
- 发过去的消息比较大
- 如下改进流程:
-
详细流程图
- 注意:
- Bob获取到的是:公钥、消息明文、消息签名
- 消息签名是用Alice的私钥加密签名的
- 签名的不是消息体本身,而是消息体的单向函数散列值
- 注意:
- 上面那个流程还是有一些问题的
- 数字签名 – 疑惑
- 思考一下
- 如果有人篡改了文件内容或者签名内容,会是什么结果?
- 结果是:签名验证失败,证明内容会篡改
- 数字签名不能保证机密性?
- 数字签名的作用不是为了保证机密性,仅仅是为了能够识别内容有没有被篡改
- 数字签名的作用
- 确认消息的完整性
- 识别消息是否被篡改
- 防止消息发送人否认
- 思考一下
- 数字签名无法解决的问题
- 要正确使用签名,前提是
- 用于验证签名的公钥必须属于真正的发送者
- 如果遭遇了中间人攻击(看下面的8解释),那么
- 公钥将是伪造的
- 数字签名将失效
- 所以在验证签名之前,首先得先验证公钥的合法性
- 如何验证公钥的合法性?(证书的作用)
- 证书
- 要正确使用签名,前提是
- 在使用公钥密码时,还有一种中间人攻击的可能性,如下图:(注意这个不是数字签名,仅仅是公钥密码)
证书(Certificate)
- 证书,联想的是驾驶证、毕业证、英语四六级证等等,都是由权威机构认证的
- 密码学中的证书,全称叫公钥证书(Public-key Certificate,PKC),跟驾驶证类似
- XX:里面有姓名、邮箱等个人信息,以及此人的公钥
- 并由认证机构(Certificate Authority,CA)施加数字签名
- 将 XX:中的数据通过散列函数先生成散列值
- 通过CA的私钥签名,就是CA数字签名
- CA就是能够认定“公钥确实属于此人”并能够生成数字签名的个人或者组织
- 有国际性组织、政府设立的组织
- 有通过提供认证服务来盈利的企业
- 个人也可以成立认证机构
- 证书的利用
- 证书的注册和下载
- Bob向认证机构CA注册证书
- CA生成证书,存储到自己的仓库
- Alice 到CA仓库去下载Bob申请的证书。