一、预备知识
1、常见英文
encrypt：加密
decrypt：解密
plaintext：明文
ciphertext：密文
2、为了便于学习，设计4个虚拟人物
Alice、Bob：互相通信
Eve：窃听者
Mallory：主动攻击者
image
image
如何防止被窃听？
image
如何加密解密？
image
二、密码的类型
根据密钥的使用方法，可以将密码分为2种
- 对称密码
- 公钥密码（非对称密码）
image
image
三、对称密码（Symmetric Cryptography）
在对称密码中，加密、解密时使用的是同一个密钥
常见的对称密码算法有
- DES
- 3DES
- AES
image
1、DES（Data Encryption Standard）
DES是一种将64bit明文加密成64bit密文的对称密码算法，密钥长度是56bit
规格上来说，密钥长度是64bit，但每隔7bit会设置一个用于错误检查的bit，因此密钥长度实质上是56bit
由于DES每次只能加密64bit的数据，遇到比较大的数据，需要对DES加密进行迭代（反复）
目前已经可以在短时间内被破解，所以不建议使用
image
image
2、3DES
3DES，将DES重复3次所得到的一种密码算法，也叫做3重DES
目前还被一些银行等机构使用，但处理速度不高，安全性逐渐暴露出问题
3个密钥都是不同的，也称为DES-EDE3
image
image
如果所有密钥都使用同一个，则结果与普通的DES是等价的
image
如果密钥1、密钥3相同，密钥2不同，称为DES-EDE2
image
3、AES（Advanced Encryption Standard）
取代DES成为新标准的一种对称密码算法
AES的密钥长度有128、192、256bit三种
在2000年时选择Rijindael算法作为AES的实现
目前AES，已经逐步取代DES、3DES，成为首选的对称密码算法
一般来说，我们也不应该去使用任何自制的密码算法，而是应该使用AES，它经过了全世界密码学家所进行的高品质验证工作
4、密钥配送问题
在使用对称密码时，一定会遇到密钥配送问题
假设，Alice将使用对称密码加密过的消息发给了Bob
只有将密钥发送给Bob，Bob才能完成解密
在发送密钥过程中，可能会被Eve窃取密钥，最后Eve也能完成解密
image
如何解决密钥配送问题
有以下几种解决密钥配送的方法
- 事先共享密钥
- 密钥分配中心
- Diffie-Hellman密钥交换
- 公钥密码
四、公钥密码（Public-key Cryptography）
公钥密码中，密钥分为加密密钥、解密密钥2种，它们并不是同一个密钥
公钥密码也被称为非对称密码（Asymmetric Cryptography）
在公钥密码中
加密密钥，一般是公开的，因此该密钥称为公钥（public key）
解密密钥，由消息接收者自己保管的，不能公开，因此也称为私钥（private key）
公钥和私钥是一 一对应的，是不能单独生成的，一对公钥和密钥统称为密钥对（key pair）
由公钥加密的密文，必须使用与该公钥对应的私钥才能解密
由私钥加密的密文，必须使用与该私钥对应的公钥才能解密
image
解决密钥配送问题
由消息的接收者，生成一对公钥、私钥
将公钥发给消息的发送者
消息的发送者使用公钥加密消息
image
RSA
目前使用最广泛的公钥密码算法是RSA
RSA的名字，由它的3位开发者，即Ron Rivest、Adi Shamir、Leonard Adleman的姓氏首字母组成
五、混合密码系统（Hybrid Cryptosystem）
1、对称密码的缺点
不能很好地解决密钥配送问题
2、公钥密码的缺点
加密解密速度比较慢
3、混合密码系统，是将对称密码和公钥密码的优势相结合的方法
解决了公钥密码速度慢的问题
并通过公钥密码解决了对称密码的密钥配送问题
网络上的密码通信所用的SSL/TLS都运用了混合密码系统
4、混合密码-加密
会话密钥（session key）
为本次通信随机生成的临时密钥
作为对称密码的密钥，用于加密消息，提高速度
加密步骤（发送消息）
首先，消息发送者要拥有消息接收者的公钥
生成会话密钥，作为对称密码的密钥，加密消息
用消息接收者的公钥，加密会话密钥
将前2步生成的加密结果，一并发给消息接收者
发送出去的内容包括
用会话密钥加密的消息（加密方法：对称密码）
用公钥加密的会话密钥（加密方法：公钥密码）
image
5、混合密码-解密
解密步骤（收到消息）
-
消息接收者用自己的私钥解密出会话密钥
-
再用第1步解密出来的会话密钥，解密消息
image
6、混合密码-加密解密流程
Alice >>>>> Bob
发送过程，加密过程
1.Bob先生成一对公钥、私钥
2.Bob把公钥共享给Alice
3.Alice随机生成一个会话密钥（临时密钥）
4.Alice用会话密钥加密需要发送的消息（使用的是对称密码加密）
5.Alice用Bob的公钥加密会话密钥（使用的是公钥密码加密，也就是非对称密码加密）
6.Alice把第4、5步的加密结果，一并发送给Bob
接收过程，解密过程
1.Bob利用自己的私钥解密会话密钥（使用的是公钥密码解密，也就是非对称密码解密）
2.Bob利用会话密钥解密发送过来的消息（使用的是对称密码解密）
六、单向散列函数（One-way hash function）
单向散列函数，可以根据根据消息内容计算出散列值
散列值的长度和消息的长度无关，无论消息是1bit、10M、100G，单向散列函数都会计算出固定长度的散列值
image
image
1、单向散列函数的特点
根据任意长度的消息，计算出固定长度的散列值
计算速度快，能快速计算出散列值
消息不同，散列值也不同
具备单向性
image
image
2、单向散列函数
单向散列函数，又被称为消息摘要函数（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
全新标准
3、如何防止数据被篡改
image
image
4、单向散列函数的应用 – 防止数据被篡改
image
image
5、单向散列函数的应用 – 口令加密
image
七、数字签名
想象以下场景
image
Alice发的内容有可能是被篡改的，或者有人伪装成Alice发消息，或者就是Alice发的，但她可以否认
问题来了：Bob如何确定这段消息的真实性？如何识别篡改、伪装、否认？
解决方案
- 数字签名
1、数字签名
在数字签名技术中，有以下2种行为
-
生成签名
由消息的发送者完成，通过“签名密钥”生成 -
验证签名
由消息的接收者完成，通过“验证密钥”验证
思考
如何能保证这个签名是消息发送者自己签的？
答案
用消息发送者的私钥进行签名
image
image
2、数字签名和公钥密码
数字签名，其实就是将公钥密码反过来使用
image
3、数字签名的过程
image
4、数字签名的过程 – 改进
image
image
5、数字签名 – 疑惑
-
思考一下
如果有人篡改了文件内容或者签名内容，会是什么结果？
结果是：签名验证失败，证明内容会篡改 -
数字签名不能保证机密性？
数字签名的作用不是为了保证机密性，仅仅是为了能够识别内容有没有被篡改 -
数字签名的作用
确认消息的完整性
识别消息是否被篡改
防止消息发送人否认
6、数字签名无法解决的问题
-
要正确使用签名，前提是
用于验证签名的公钥必须属于真正的发送者 -
如果遭遇了中间人攻击，那么
公钥将是伪造的
数字签名将失效 -
所以在验证签名之前，首先得先验证公钥的合法性
-
如何验证公钥的合法性？
证书
image
八、证书（Certificate）
-
证书，联想的是驾驶证、毕业证、英语四六级证等等，都是由权威机构认证的
-
密码学中的证书，全称叫公钥证书（Public-key Certificate，PKC），跟驾驶证类似
里面有姓名、邮箱等个人信息，以及此人的公钥
并由认证机构（Certificate Authority，CA）施加数字签名 -
CA就是能够认定“公钥确实属于此人”并能够生成数字签名的个人或者组织
有国际性组织、政府设立的组织
有通过提供认证服务来盈利的企业
个人也可以成立认证机构
1、证书的利用
image
2、证书的注册和下载
image
九、iOS签名机制
-
iOS签名机制的作用
保证安装到用户手机上的APP都是经过Apple官方允许的 -
不管是真机调试，还是发布APP，开发者都需要经过一系列复杂的步骤
生成CertificateSigningRequest.certSigningRequest文件
获得ios_development.cer\ios_distribution.cer证书文件
注册device、添加App ID
获得*.mobileprovision文件 -
对于真机调试，现在的Xcode已经自动帮开发者做了以上操作
-
思考
每一步的作用是什么？
.certSigningRequest、.cer、.mobileprovision文件究竟里面包含了什么？有何用处？
1、iOS签名机制 – 流程图
image
2、iOS签名机制 – 生成Mac设备的公私钥
CertificateSigningRequest.certSigningRequest文件
就是Mac设备的公钥
image
3、iOS签名机制 – 获得证书
image
4、ios_development.cer、ios_distribution.cer文件
利用Apple后台的私钥，对Mac设备的公钥进行签名后的证书文件
image
5、iOS签名机制 – 生成mobileprovision
image
image
6、iOS签名机制 – 安全检测
image
7、iOS签名机制 - AppStore
如果APP是从AppStore下载安装的，你会发现里面是没有mobileprovision文件的
它的验证流程会简单很多，大概如下所示
image
十、重签名
-
如果希望将破坏了签名的安装包，安装到非越狱的手机上，需要对安装包进行重签名的操作
-
注意
安装包中的可执行文件必须是经过脱壳的，重签名才会有效
.app包内部的所有动态库（.framework、.dylib）、AppExtension（PlugIns文件夹，拓展名是appex）、WatchApp（Watch文件夹）都需要重新签名 -
重签名打包后，安装到设备的过程中，可能需要经常查看设备的日志信息
程序运行过程中：Window -> Devices and Simulators -> View Device Logs
程序安装过程中： Window -> Devices and Simulators -> Open Console
1、重签名步骤
-
准备一个embedded.mobileprovision文件（必须是付费证书产生的，appid、device一定要匹配），并放入.app包中
可以通过Xcode自动生成，然后在编译后的APP包中找到
可以去开发者证书网站生成下载 -
从embedded.mobileprovision文件中提取出entitlements.plist权限文件
security cms -D -i embedded.mobileprovision > temp.plist
/usr/libexec/PlistBuddy -x -c 'Print :Entitlements' temp.plist > entitlements.plist -
查看可用的证书
security find-identity -v -p codesigning -
对.app内部的动态库、AppExtension等进行签名
codesign -fs 证书ID xxx.dylib -
对.app包进行签名
codesign -fs 证书ID --entitlements entitlements.plist xxx.app
2、重签名GUI工具
-
iOS App Signer
https://github.com/DanTheMan827/ios-app-signer -
可以对.app重签名打包成ipa
需要再.app包中提供对应的embedded.mobileprovision文件 -
可以对ipa进行重签名
需要提供entitlements.plist、embedded.mobileprovision文件的路径
3、动态库注入
-
可以使用insert_dylib库将动态库注入到Mach-O文件中
https://github.com/Tyilo/insert_dylib -
用法
insert_dylib 动态库加载路径 Mach-O文件
有2个常用参数选项
--weak，即使动态库找不到也不会报错
--all-yes，后面所有的选择都为yes
-
insert_dylib的本质是往Mach-O文件的Load Commands中添加了一个LC_LOAD_DYLIB或LC_LOAD_WEAK_DYLIB
-
可以通过otool查看Mach-O的动态库依赖信息
otool -L Mach-O文件
4、更改动态库加载地址
-
可以使用install_name_tool修改Mach-O文件中动态库的加载地址
install_name_tool -change 旧地址 新地址 Mach-O文件 -
通过Theos开发的动态库插件（dylib）
默认都依赖于/Library/Frameworks/CydiaSubstrate.framework/CydiaSubstrate
如果要将动态库插件打包到ipa中，也需要将CydiaSubstrate打包到ipa中，并且修改下CydiaSubstrate的加载地址 -
2个常用环境变量
@executable_path代表可执行文件所在的目录
@loader_path代表动态库所在的目录
网友评论