iOS安全之数字证书和安全机制


上是我们从苹果MC中申请的所有证书的“根证书”,安装这个证书意味着我们的开发工具对此CA的信任,从而可以用此CA签发的其他证书进行签名和打包。一般而言,如果安装了Xcode,那么这个证书是自动安装……里面是iOS设备的UDID,每台iOS设备出厂的UDID都不同,所以可以用来标识设备。 苹果的签名。注意,这里的签名是苹果签的,跟我们的私钥没有关系。也就是说mobileprovision文件是苹果……。对于开发时候的真机调试,原理差不多。都是通过mobileprovision的条目4来做到的。而苹果对于调试和测试用机的数量限制为100台! iOS代码签名 ipa的组成 iOS程序最终都会以.ipa……,2449,1,6,iOS安全之数字证书和安全机制

非对称加密和摘要

非对称加密就是指加密密钥和解密密钥是不同的,而且加密密钥和解密密钥是成对出现。非对称加密又叫公钥加密,也就是说成对的密钥,其中一个是对外公开的,所有人都可以获得,称为公钥,而与之相对应的称为私钥,只有这对密钥的生成者才能拥有。公私钥具有以下重要特性:

对于一个私钥,有且只有一个与之对应的公钥。生成者负责生成私钥和公钥,并保存私钥,公开公钥。

公钥是公开的,但不可能通过公钥反推出私钥,或者说极难反推,所以只要秘钥足够长度,要通过穷举而得到私钥,几乎是不可能的。

通过私钥加密的密文只能通过公钥解密,公钥加密的密文只有通过私钥解密。

由于上述特性,非对称加密具有以下的典型用法:

对信息保密,防止中间人攻击:将明文通过接收人的公钥加密,传输给接收人,因为只有接收人拥有对应的私钥,别人不可能拥有或者不可能通过公钥推算出私钥,所以传输过程中无法被中间人截获。只有拥有私钥的接收人才能阅读。此用法通常用于交换对称密钥。

身份验证和防止篡改:权限狗用自己的私钥加密一段授权明文,并将授权明文和加密后的密文,以及公钥一并发送出来,接收方只需要通过公钥将密文解密后与授权明文对比是否一致,就可以判断明文在中途是否被篡改过。此方法用于数字签名。

著名的RSA算法就是非对称加密算法,RSA以三个发明人的首字母命名。

非对称加密算法如此强大可靠,却有一个弊端,就是加解密比较耗时。因此,在实际使用中,往往与对称加密和摘要算法结合使用。

对称加密是将明文(原始数据)和加密密钥(mi yao)一起经过特殊加密算法处理后,使其变成复杂的加密密文发送出去。收信方收到密文后,若想解读原文,则需要使用加密用过的密钥及相同算法的逆算法对密文进行解密,才能使其恢复成可读明文。在对称加密算法中,使用的密钥只有一个,发收信双方都使用这个密钥对数据进行加密和解密,这就要求解密方事先必须知道加密密钥。计算机专网系统中广泛使用的对称加密算法有DES和IDEA等。

摘要算法可以将任意长度的文本,通过一个算法,得到一个固定长度的文本。这里文本不一定只是文本,可以是字节数据。所以摘要算法试图将世间万物,变成一个固定长度的东西。摘要算法具有以下重要特性:

只要源文本不同,计算得到的结果,必然不同。

无法从结果反推出源。

典型的摘要算法,比如大名鼎鼎的MD5和SHA。摘要算法主要用于比对信息源是否一致,因为只要源发生变化,得到的摘要必然不同;而且通常结果要比源短很多,所以称为“摘要”。

数字签名

数字签名一般用于数据接收方(一般指客户端)验证数据发送发方(一般只指代服务器)发送的数据是否合法(是否经过第三方篡改)。举个例子,A有一段文本要发给B,A为了防止文本在中途被恶意篡改。A找来C,C将文本内容通过摘要算法,得到摘要,再用自己(C的)私钥对摘要加密得到密文,A将原文、密文一并发给B。接收方B收到数据以后用C的公钥(提前固化在系统中了)对密文进行解密,将文本用同样的算法得到摘要,两个摘要进行对比,如果相等那么一切正常,否则视为接收数据视为无效。如图:

数字签名可以快速验证文本的完整性和合法性。

数字证书

数字证书就是通过数字签名实现的数字化的证书。在一般的证书组成部分中,还加入了其他的信息,比如证书有效期,过了有效期,需要重新签发。

数字证书的签发机构也有若干,并有不同的用处。比如苹果公司就可以签发跟苹果公司有关的证书,而跟web访问有关的证书则是又几家公认的机构进行签发。这些签发机构称为CA(Certificate Authority)。我们的app要想运行在iPhone上,就要从苹果申请相关的证书。而iOS设备在运行我们的app之前,首先验证证书是否合法,然后再通过证书中的公钥验证程序是不是我们发布的,中间有没有被修改。

iOS证书申请和打包

流程图

证书申请

开发iOS程序必然进行的工作就是成为开发者,并申请相关的证书。在申请之前需要:

支付$99或$299成为苹果开发者,并每年续费,$99针对个人和小企业,$299针对大企业。

安装苹果开发者根证书,此证书实际上是我们从苹果MC中申请的所有证书的“根证书”,安装这个证书意味着我们的开发工具对此CA的信任,从而可以用此CA签发的其他证书进行签名和打包。一般而言,如果安装了Xcode,那么这个证书是自动安装在Key Chain中了。

CertificateSigningRequest.certSigningRequest

我们需要生成一个CertificateSigningRequest.certSigningRequest文件来提交到MC中,从而获取某种证书。这个文件包含两部分内容:

申请者信息,此信息是用申请者的私钥加密的。

申请者公钥,此信息是申请者使用的私钥对应的公钥。

摘要算法和公钥加密算法。

从MC中申请到的证书

证书中最为重要的是我的公钥,这个公钥与我本机的私钥是对应的。当我们双击安装完证书后,KeyChain会自动将这对密钥关联起来。后续在程序上真机的过程中,会使用这个私钥,对代码进行签名,而公钥会附带在mobileprovision文件中,打包进app。所以,就算你有证书,但是如果没有对应的私钥是没有用的。

团队开发

打包到真机上的app需要我们的私钥进行签名,所以我们在团队开发中需要公开私钥。将最初申请证书的机器的私钥导出成.p12文件,并让其他机器导入,同时其他机器也应该安装下载下来的证书。

由于iOS证书有多种类型,用于不同的用处,所以我们可能后续还会去MC上申请别的证书。所以强烈建议CertificateSigningRequest.certSigningRequest需要保留,因为如果再次生成CertificateSigningRequest.certSigningRequest文件,可能就是对应另一个私钥了!还需要在共享一次私钥,会比较麻烦。

iOS证书类型

常用的有:

iOS App Development。开发、真机调试用。

Apple Push Notification service SSL (Sandbox)。开发阶段使用苹果的推送服务。

App Store and Ad Hoc。上架和AdHoc方式发布时用。

Apple Push Notification service SSL (Production)。上架后使用苹果推送服务。

In-House。企业版发布,需$299才能拥有,还需邓氏编码。

iOS授权和描述文件

可以使用如下命令查看描述文件。

security cms -D -i embedded.mobileprovision

mobileprovision文件包含:

AppId。每个app必须在MC中创建一个对应的AppId。

使用哪些证书。不同类型的证书就代表了不同的发布方式,还包括一些功能的能否使用(比如APN)。

功能授权列表。

可安装的设备列表。对于AdHoc方式发布的app或者真机调试时,会有一个列表,这个列表里面是iOS设备的UDID,每台iOS设备出厂的UDID都不同,所以可以用来标识设备。

苹果的签名。

注意,这里的签名是苹果签的,跟我们的私钥没有关系。也就是说mobileprovision文件是苹果签名的,我们除了从MC中获取,别无他法。也不能再获取后随意篡改(比如添加别的设备)。

AdHoc发布和真机调试

AdHoc允许将测试版app发布给有限的设备安装,而无需通过appstore的审核。这里的关键是如何控制哪些设备可以装。答案就是mobileprovision文件,记得你在生成mobileprovision文件的时候需要选设备的UDID吧,所以这些设备需要事先添加到MC的Devices里面。对于开发时候的真机调试,原理差不多。都是通过mobileprovision的条目4来做到的。而苹果对于调试和测试用机的数量限制为100台!

iOS代码签名

ipa的组成

iOS程序最终都会以.ipa(事实上,ipa文件只是一个zip包)文件导出,先来了解一下ipa文件的结构:

将appname.ipa的后缀名改成appname.zip然后解压,得到上图的Payload目录,下面是个子目录,其中的内容如下。

资源文件,例如图片、html、等等。

_CodeSignature/CodeResources。这是一个plist文件,可用文本查看,其中的内容就是是程序包中(不包括Frameworks)所有文件的签名。注意这里是所有文件。意味着你的程序一旦签名,就不能更改其中任何的东西,包括资源文件和可执行文件本身。iOS系统会检查这些签名。

可执行文件。此文件跟资源文件一样需要签名。

一个mobileprovision文件.打包的时候使用的,从MC上生成的。

Frameworks。程序引用的非系统自带的Frameworks,每个Frameworks其实就是一个app,其中的结构应该和app差不多,也包含签名信息CodeResources文件。

相关的程序和命令

一般我们会用Xcode自带的archive功能来打包ipa和签名,实际上xcode只不过是调用了一些外部程序完成了工作,如果我们有朝一日需要自己实现自动化的签名流程,就需要了解究竟相关的程序和命令有哪些。

用下面命令,列出系统中可用于签名的有效证书:

security find-identity -v -p codesigning

使用如下命令对xxx.app目录签名,codesign程序会自动将其中的文件都签名,(Frameworks不会自动签):

codesign -fs “Your Cer” --no-strict Payload/xxx.app

对于每个Framework,也需要使用这个命令签名,上面说了Framework的结构跟app其实差不多,所以签名命令类似。这个命令会自动找到证书相关的私钥。-f表示对于已经签名的app强制重签。

最后用下面命令校验签名是否合法:

codesign -v xxx.app

使用zip命令重新打包成ipa包

zip -qry destination source

对app重新签名的流程

如果要设计一个自动化的重签程序,大致需要这么个流程:

解压ipa。

如果mobileprovision需要替换,替换。

如果存在Frameworks子目录,则对.app文件夹下的所有Frameworks进行签名,在Frameworks文件夹下的.dylib或.framework。

对xxx.app签名。

重新打包。

iOS设备如何验证app是否合法

解压ipa。

取出embedded.mobileprovision,通过签名校验是否被篡改过。

其中有几个证书的公钥,其中开发证书和发布证书用于校验签名。

BundleId。

授权列表。

校验所有文件的签名,包括Frameworks。

比对Info.plist里面的BundleId是否符合embedded.mobileprovision文件中的。

企业签名QQ:281442504

分享到