准备知识:非对称加密
一、理论
首先说到非对称加密,大家都熟知一个算法,RSA(又三位数学家名字首字母构成),这个算法中包含很多数学公式和理论证明,这里就不做深究。我们来简单地理解下非对称加密的思想。
先来看看对称加密的过程,对称加密的双方都保持相同的加密密钥和解密密钥,数据经过加密密钥加密之后再网络中传输,对称加密最大的问题就是解密秘钥的如何安全传输。
再来看看非对称加密,非对称加密有两个密钥,公钥和私钥,公钥公开,私钥私有。
二、非对称加密的例子
1.加密:
A想要传输信息给B,那么B首先生成公钥和私钥,公钥发送给A,私钥保留,A收到B的公钥之后,将信息利用公钥加密,然后传输给B,B通过私钥解密。
2.防止篡改:
B想要给A发送一个证明,那么B首先生成公钥和私钥,利用私钥加密证明生成加密文件,然后将证明和加密文件以及公钥一同发送给A,A收到之后,利用公钥将加密文件解密,然后对比证明,如果相同,则可以认为证明没有被篡改过。
苹果的数字签名
苹果生成了一对密钥,公钥安装在每台iOS设备上,私钥保存在苹果后台服务器中,当APP上架到Appstore的时候,苹果后台用私钥对App进行签名(加密),当用户使用iOS设备下载App时,利用设备中的公钥验证签名,如果签名正确,那么可以认为该App是被官方认证的,同时也没有被修改过。
上面的逻辑很通俗易懂,当然,这只是最简单的逻辑。考虑到很多实际情况,苹果制定了更为复杂的签名机制。
实际情况
开发者可以直接把开发中的应用安装进手机进行调试
更复杂的签名机制
一、签名
-
首先在Mac机器中生成一对公钥和私钥,这里标记为公钥M,私钥M(M:Mac)
-
同样苹果仍然持有一对密钥,公钥放在iOS设备上,私钥放在后台服务器,这里标记为公钥A,私钥A(A:Apple)
-
签名:
1.将公钥M上传到后台服务器,通过私钥A进行签名,然后返回签名和公钥M,将其称为证书
2.用私钥M对App签名
-
将以上两者内容打包,安装在手机上
二、验证
-
首先利用设备中的公钥A对证书中的签名进行验证,确保公钥M是是认证过的
-
然后利用公钥钥M对App签名进行验证,确保App是认证过的
更完善的策略设计
以上是签名的大致过程,但是苹果还加了两个限制:
-
只有在后台注册过的设备才能安装
-
签名机制应该针对具体的某一App
完善的签名机制
做一些小调整
-
在签名过程中,原来只讲私钥M上传后台服务器,现在需要将设备的IDs和AppID以及Entitlements(权限开关)也传入到后台服务器
-
先利用私钥A签名得到证书,然后将证书和添加的信息打包后再用私钥签名(由一次签名变成两次签名,验证也从一次变成两次)
-
在验证过程中,添加了两项验证:
1.用设备IDs验证iOS设备是否属于注册的设备范围
2.用AppID验证App的ID是否对应
概念与实际操作对应
一、签名
-
在keychain中选择“从证书颁发机构请求证书”,可以在本地生成一对公钥私钥,私钥保存在电脑中,公钥为生成的CertificateSigningRequest
-
iOS系统中保存一个公钥,苹果后台保存一个私钥
-
签名:
1.将CertificateSigningRequest上传到服务器进行证书的申请,然后在网页上设置设备的IDs、AppID和Entitlements,配置完成后即可下载Provisioning Profile文件(该文件中包含证书、设备IDs、AppID、Entitlements)
2.Xcode通过Provisioning Profile中的本地公钥可以找到对应的私钥(如果其他机器想要编译这个APP,则需要将私钥导出,为.p12文件),并签名该App,接着把Provisioning Profile文件命名为embedded.mobileprovision一同打包
二、验证
-
先用公钥验证证书和附加信息的包的签名,然后再验证证书的签名
-
利用公钥验证App签名
-
利用附加信息验证
转自:http://www.cocoachina.com/appstore/20171225/21642.html