久等，最近一直很忙，代码实在写的无聊，然后确实有想要了解和总结这方面的知识，就写了这篇文章。
申明：这可能只是一个读后感，关于一片《漫谈iOS程序的证书和签名机制》的一些理解（或者说用自己的方式描述一遍之类的），打开有问题的同学可以查看segmentfault上面的转载。
加密算法
按照原文的写法，我们先来讲一下几个比较基础的加密算法。世上无难事，只怕有心人，任何的加密算法都是可以破解的，设置一些加密算法无非只是提高门槛罢了，高玩们看到这些粗浅的加密算法千万别喷，嘴下留情。
对称加密
可以先讲讲对称的加密，就是加密的密钥和解密的密钥是同一个，举个栗子就是你的宝库的开门钥匙和锁门钥匙是同一把，假如有人拿到这把钥匙，就能够进入宝库，把里面的宝物全部偷光，过分点，还可以拉两坨屎再走。然后当不懂事的小虎子拿着你给他的钥匙来宝库拿宝物的时候，就会开开心心的拿着两坨屎，带在身上。好蠢，讲不下去了，大概就是这么个意思。</br>
稍微专业点的描述就是，当你使用密钥加密你的数据，在传输过程中，如果有人窃取过你的密钥，那么，他能够篡改你的数据，而接收到的人却全然不知。</br>
用图来表示大概是这样:
非对称加密
非对称加密和对称加密相反，它有两个密钥，一个我们叫做私钥（secret key），一个叫做公钥(public key)，通过私钥加密的数据只有通过公钥才能解密，通过公钥加密的数据只有私钥才能够解密，而且公钥和私钥唯一对应，且很难或者不可能互相推导，再拿同一个比方，开门和锁门的钥匙是两把，锁门的钥匙只有自己持有，而把开门的钥匙交给别人，这样，当别人获取到相对较易获取的公钥的时候，那个人能够打开你的宝库，但是当他偷取里面的宝物再锁上门的时候是没有钥匙的，我们就能清楚的知道宝库是否被窃贼关顾过，从而考虑是不是要换一组钥匙，而去取宝物的人，也不会很蠢的拿着里面的垃圾当宝物了。</br>
再用专业点的话来描述就是：你会使用只有你自己持有，并相对安全的私钥较密数据，假如公钥的持有者很不小心的把公钥泄露了，那么造成的影响最大是数据被剽窃，但绝不会被篡改，一旦被篡改，我们能够马上知晓并作出相应地应对策略。</br>
但经过这番了解，我发现非对称加密算法应该只是单向安全的，假如从数据从对方发来，如果使用公钥加密数据，那么在中途就可能有机会篡改，所以就必须要使用另一套公钥私钥。所以其实各大第三方的平台都会给其开发者开出一个公钥，一个私钥，而这对公钥私钥在我理解来看应该是不对应的，而应该是和其平台上的一对公钥私钥相对应。
摘要算法
摘要算法是一段很神奇的算法，它的功能是更具一段很长的数据，它能够计算出一段唯一且很短的数据。使用这种技术可以用一段较短的数据标示一段很长的数据或者文件，比较著名的有MD5和SHA算法。想起git和svn的区别，svn在记录每一个commit的时候，只是使用一个计数器，每次加1，而git在记录commit的时候就是使用SHA的算法，计算这个项目的SHA值，用这个值作为这次commit的唯一标示。SHA和MD5加密不可逆，所以现在很多账号密码服务中，也会使用这两种算法。
数字签名
非对称加密中比较著名的加密算法有个叫做RSA加密算法，但他似乎并不是最好的，但是从参考文中，我们可以知晓，苹果证书使用的非对称加密算法就是RSA加密算法，那么RSA有个很致命的缺点，就是这个算法的速度特别慢，让我想起大学信息安全导论课上实现的一个文件加密应用，我们使用了对称加密的方式加密了文件，但是我们使用了RSA加密的算法加密了对称加密的秘钥，这样可以做到在保证一定的安全性的情况下提高了效率。而数字签名应该也是做了差不多的事情，当我们拿到文件的时候，我们首先使用摘要算法获取文件的摘要，再使用RSA算法用私钥加密文件摘要，然后将加密过后的摘要和源文件发送出去，当对方接收到数据的时候，同样使用摘要算法对源文件摘要，然后将加密后的摘要使用公钥解密，比对两端摘要就能知晓数据的真实性。
大致的流程，在参考文中有张图我觉得很不错，这里就直接放上来了：
.cer文件
生成这个文件需要我们本地的CertificateSigningRequest.certSigningRequest文件，而CertificateSigningRequest.certSigningRequest中包含了RSA的一对秘钥，而当我们上传CertificateSigningRequest.certSigningRequest文件的时候，苹果会，获取里面的私钥，然后结合Member Center中的用户信息来生成一个.cer文件，于是.cer中就包含了我们这台电脑的公钥和Member Center的个人信息，当我们下载.cer文件并双击之后，.cer就会找到我们电脑本地的对应的私钥，形成一个有效地.cer文件并记入keychain中，如果本地没有的私钥，就不能形成一个有效.cer文件，在keychain中这个.cer文件属于缺失私钥的。
所以，在团队协作中，一种方式是导出创建者的私钥生成的.p12文件，然后大家使用同一个app账号和同一个.cer文件，或者使用不同的账号和不同的CertificateSigningRequest.certSigningRequest的文件生成不同的.cer文件，不然很有可能会出现问题。
.mobileprovision文件
.mobileprovision是一个配置文件，而且是Member Center中按照创建设置设定的，由于其含有苹果的数字签名，下载后不可修改，主要的配置内容有
- AppId。每个app必须在MC中创建一个对应的AppId。规则不累述了。
- 使用哪些证书。上面说了，不同类型的证书就代表了不同的发布方式，还包括一些功能的能否使用（比如APN）
- 功能授权列表
- 可安装的设备列表。对于AdHoc方式发布的app或者真机调试时，会有一个列表，这个列表里面是iOS设备的UDID，每台iOS设备出厂的UDID都不同，所以可以用来标识设备。可通过iTunes连接设备，或者http://fir.im/udid这里获取
此外，.mobileprovision还包含了这个app的签名的公钥，但是我们实际上不会使用这个公钥来加密，我真是说了一句废话，想想也知道，私钥只有你自己的机器上有，如果使用私钥来加密签名，那还有谁可以解密签名验证。
所以，在打包的时候，我们会通过.mobileprovision描述的公钥的对应的私钥对整个项目经行数字签名。
当使用者获取到项目之后，.mobileprovision中的公钥对各个签名经行解密对照之后就能知道项目的真实性和完整性。
总结
在Member Center中应该也就这两个文件比较重要，.cer的作用主要在于验证开发者的信息，. mobileprovision的作用主要在于连接app的各方面设置和开发者的信息。而前面讲到的算法主要作用于几个文件在上传下载过程中的验证，还有在发布和用户下载的包的验证。若未完，再待续。。。。。。
网友评论