iOS开发中的数字证书是Apple,而且加密密钥和解密

2019-09-17 20:25栏目:大奖888官网登录
TAG:

本想自己查阅资料总结一篇ios签名授权机制,但写着写着发现这篇已经总结概括的很好了,没什么好多说的,就直接把推酷上的搬到了简书上,以供更多网友学习。原文链接

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

作者comst

、几个重要的概念

对什么是RSA、MD5、AES加密概念可以看这里

  1. 非对称加密非对称加密算法需要两个密钥: 公开密钥(publickey )和 私有密钥(privatekey) 。公开密钥与私有密钥是一对,如果用公开密钥对数据进行加密,只有用对应的私有密钥才能解密;如果用私有密钥对数据进行加密,那么只有用对应的公开密钥才能解密。(私钥是要保密的,公钥可以公开) RSA 是目前最有影响力的公钥加密算法,它能够抵抗到目前为止已知的绝大多数密码攻击,已被ISO推荐为公钥数据加密标准。 RSA 是以三个发明者的姓氏首字母组成的。

  2. 摘要算法数据摘要算法是密码学算法中非常重要的一个分支,它通过对所有数据提取指纹信息以实现数据签名、数据完整性校验等功能,由于其不可逆性,有时候会被用做敏感信息的加密。数据摘要算法也被称为哈希算法、散列算法。 摘要算法也可以理解为将任意长度的数据,通过一个算法,得到一个固定长度的数据。典型的摘要算法,比如大名鼎鼎的 MD5 和 SHA 。

  3. 数字签名数字签名就是利用 非对称加密 和 摘要算法 来传输数据,保证数据的 完整性 和 合法性 。验证过程如下: 1. 发送方使用给一个摘要算法得到要发送数据的摘要,然后用自己的私钥和一个非对称加密算法对得到的摘要加密,得到加密后的数据,然后将 要发送的数据 、 加密后的数据 、 摘要算法 和 加密算法 一同发送给接收方。 2. 接收方接收到数据后,根据指定的摘要算法得到实际要传输的数据的摘要,然后在根据指定的加密算法和已有的公钥解密得到加密数据解密后的数据,最后比较解密后的数据和得到的摘要是否相同,如果相同就说明实际要传输的数据是完成的合法的。

图片 1数字签名流程图

4. 数字证书数字证书就是通过数字签名方式来传输的一段数据,iOS开发中的数字证书是Apple Worldwide Developer Relations Certification Authority证书认证中心数字签名过的数据,表面上我们看到的就是钥匙串中的证书,实际WWDR数字签名后的证书包含以下内容:

  • 用户的公钥
  • 用户信息
  • 证书机构名称
  • 证书有效期
  • 苹果数字签名 : 用于验证以上信息
非对称加密和摘要

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

  • 对于一个私钥,有且只有一个与之对应的公钥。生成者负责生成私钥和公钥,并保存私钥,公开公钥。
  • 公钥是公开的,但不可能通过公钥反推出私钥,或者说极难反推,所以只要秘钥足够长度,要通过穷举而得到私钥,几乎是不可能的。
  • 通过私钥加密的密文只能通过公钥解密,公钥加密的密文只有通过私钥解密。
    由于上述特性,非对称加密具有以下的典型用法:
  • 对信息保密,防止中间人攻击:将明文通过接收人的公钥加密,传输给接收人,因为只有接收人拥有对应的私钥,别人不可能拥有或者不可能通过公钥推算出私钥,所以传输过程中无法被中间人截获。只有拥有私钥的接收人才能阅读。此用法通常用于交换对称密钥
  • 身份验证和防止篡改:权限狗用自己的私钥加密一段授权明文,并将授权明文和加密后的密文,以及公钥一并发送出来,接收方只需要通过公钥将密文解密后与授权明文对比是否一致,就可以判断明文在中途是否被篡改过。此方法用于数字签名
    著名的RSA算法就是非对称加密算法,RSA以三个发明人的首字母命名。
    非对称加密算法如此强大可靠,却有一个弊端,就是加解密比较耗时。因此,在实际使用中,往往与对称加密和摘要算法结合使用。
    对称加密是将明文(原始数据)和加密密钥(mi yao)一起经过特殊加密算法处理后,使其变成复杂的加密密文发送出去。收信方收到密文后,若想解读原文,则需要使用加密用过的密钥及相同算法的逆算法对密文进行解密,才能使其恢复成可读明文。在对称加密算法中,使用的密钥只有一个,发收信双方都使用这个密钥对数据进行加密和解密,这就要求解密方事先必须知道加密密钥。计算机专网系统中广泛使用的对称加密算法有DESIDEA等。
    摘要算法可以将任意长度的文本,通过一个算法,得到一个固定长度的文本。这里文本不一定只是文本,可以是字节数据。所以摘要算法试图将世间万物,变成一个固定长度的东西。摘要算法具有以下重要特性:
  • 只要源文本不同,计算得到的结果,必然不同。
  • 无法从结果反推出源。
    典型的摘要算法,比如大名鼎鼎的MD5SHA。摘要算法主要用于比对信息源是否一致,因为只要源发生变化,得到的摘要必然不同;而且通常结果要比源短很多,所以称为“摘要”。

本文转载自:http://www.jianshu.com/p/d022470cef7e

二、证书申请

** 1、iOS签名验证流程图**

  • 支付$99或$299成为苹果开发者,并每年续费。
  • 安装苹果开发者根证书Apple Worldwide Developer Relations Certification Authority,一般而言,如果安装了Xcode,那么这个证书是自动安装在Key Chain中了。这证书包含了苹果CA的 公钥 。有了这个公钥,我们和Apple就可以进行互信的信息传递。整个过程大致如下:

图片 2iOS签名验证流程

** 2、证书申请流程 **

  1. 用我们自己的机器生成 CertificateSigningRequest.certSigningRequest 文件,在生成的过程中会产生一对公钥和私钥,私钥已经保存在我们的机器上,这个文件包含了我们的公钥,具体内容如下:
  • 申请者信息,此信息是用申请者的 私钥 加密的。
  • 申请者公钥,此信息是申请者使用的 私钥 对应的公钥。
  • 摘要算法和公钥加密算法
  1. 上传 CertificateSigningRequest.certSigningRequest 到 MemberCenter 。 MemberCenter 根据获取到的 公钥 和我们的用户信息,通过 Apple 自己的私钥进行数字签名生成证书,这个证书可以通过安装 Xcode 过程中安装的根证书进行验证。具体证书包含内容如下:
  • 用户的公钥
  • 用户信息
  • 证书机构名称
  • 证书有效期
  • 苹果数字签名 : 通过根证书验证以上信息
  1. 下载生成的证书,双击安装就会出现在 钥匙串 中, 钥匙串 会根据证书中的公钥对应上本机器上的私钥。

    图片 3安装证书.png

后续在程序上真机的过程中,会使用这个私钥,对代码进行签名,而公钥会附带在mobileprovision文件中,打包进app。

所以,就算你有证书,但是如果没有对应的私钥是没有用的。那么有人要问了,既然私钥只有某台电脑生成的,那么团队开发怎么展开呢?将最初申请证书的机器的私钥导出成.p12文件,并让其他机器导入,同时其他机器也应该安装下载下来的证书。所以强烈建议CertificateSigningRequest.certSigningRequest需要保留,因为如果再次生成CertificateSigningRequest.certSigningRequest文件,可能就是对应另一个私钥了!还需要在共享一次私钥,会比较麻烦。

数字签名

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

图片 4

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

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

、打包签名

  1. 下载安装配置文件mobileprovision,mobileprovision 包含如下信息:
  • appid: 每个 app 在 MemberCenter 创建的对应的 id 。
  • 包含哪些证书: 不同证书对应不同功能。
  • 功能授权列表
  • 可安装的设备列表: iOS设备的UDID列表,发布证书应该是通配。
  • 苹果数字签名: 苹果用来验证以上的信息。
  1. 通过 Xcode 指定要使用的证书,其实是 指定了签名过程中要使用的 私钥 ,因为这个私钥是和证书中的公钥相对应的。然后指定对应的 mobileprovision ,由于 mobileprovision 文件中包含了证书,实际上本地证书就是 Xcode 用来指定对应 私钥 用的。

  2. 最后通过指定的私钥对需要签名的数据进行数字签名(编译过程在签名之前,这里省略了编译过程,编译后的二进制文件也是要签名的内容),最终将 ipa 包的形式输出, ipa 的文件结构如下:

    图片 5ipa 的文件结构

** .ipa包含的内容有:**

  • 资源文件: 例如图片、html、等等。
  • _CodeSignature/CodeResources: plist文件,内容是包内所有数据的数字签名。
  • 可执行文件: 编译后的二进制文件。
  • mobileprovision: 我们之前通过Xcode指定的包含了证书的文件。
  • Frameworks: 程序引用的非系统自带的Frameworks。每个Framework的结构跟app其实差不多
  1. 解压 ipa 包,获取 embedded.mobileprovision ,通过设备上的 Apple 公钥验证该文件的完整性和安全性。
  2. embedded.mobileprovision 文件验证通过,获取该文件内的用户证书,再通过设备上的 Apple 公钥验证该证书的完整性和安全性。
  3. 证书验证通过后,获取证书内的我们开发者的公钥。然后通过开发者的公钥验证应用程序包内的数据的完整性和安全性。通过后即可安装。
数字证书

数字证书就是通过数字签名实现的数字化的证书。在一般的证书组成部分中,还加入了其他的信息,比如证书有效期,过了有效期,需要重新签发。
数字证书的签发机构也有若干,并有不同的用处。比如苹果公司就可以签发跟苹果公司有关的证书,而跟web访问有关的证书则是又几家公认的机构进行签发。这些签发机构称为CA(Certificate Authority)。我们的app要想运行在iPhone上,就要从苹果申请相关的证书。而iOS设备在运行我们的app之前,首先验证证书是否合法,然后再通过证书中的公钥验证程序是不是我们发布的,中间有没有被修改。

非对称加密和摘要

iOS证书申请和打包

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

流程图

图片 6

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

证书申请

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

  1. 支付$99或$299成为苹果开发者,并每年续费,$99针对个人和小企业,$299针对大企业。
  2. 安装苹果开发者根证书,此证书实际上是我们从苹果MC中申请的所有证书的“根证书”,安装这个证书意味着我们的开发工具对此CA的信任,从而可以用此CA签发的其他证书进行签名和打包。一般而言,如果安装了Xcode,那么这个证书是自动安装在Key Chain中了。

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

CertificateSigningRequest.certSigningRequest

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

  1. 申请者信息,此信息是用申请者的私钥加密的。
  2. 申请者公钥,此信息是申请者使用的私钥对应的公钥。
  3. 摘要算法和公钥加密算法。

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

从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文件包含:

  1. AppId。每个app必须在MC中创建一个对应的AppId。
  2. 使用哪些证书。不同类型的证书就代表了不同的发布方式,还包括一些功能的能否使用(比如APN)。
  3. 功能授权列表。
  4. 可安装的设备列表。对于AdHoc方式发布的app或者真机调试时,会有一个列表,这个列表里面是iOS设备的UDID,每台iOS设备出厂的UDID都不同,所以可以用来标识设备。
  5. 苹果的签名。
    注意,这里的签名是苹果签的,跟我们的私钥没有关系。也就是说mobileprovision文件是苹果签名的,我们除了从MC中获取,别无他法。也不能再获取后随意篡改(比如添加别的设备)。

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

AdHoc发布和真机调试

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

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

iOS代码签名

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

ipa的组成

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

图片 7

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

  1. 资源文件,例如图片、html、等等。
    1. _CodeSignature/CodeResources。这是一个plist文件,可用文本查看,其中的内容就是是程序包中(不包括Frameworks)所有文件的签名。注意这里是所有文件。意味着你的程序一旦签名,就不能更改其中任何的东西,包括资源文件和可执行文件本身。iOS系统会检查这些签名。
    2. 可执行文件。此文件跟资源文件一样需要签名。
    3. 一个mobileprovision文件.打包的时候使用的,从MC上生成的。
    4. 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重新签名的流程

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

图片 8

  1. 解压ipa。
    1. 如果mobileprovision需要替换,替换。
    2. 如果存在Frameworks子目录,则对.app文件夹下的所有Frameworks进行签名,在Frameworks文件夹下的.dylib或.framework。
    3. 对xxx.app签名。
    4. 重新打包。

无法从结果反推出源。

iOS设备如何验证app是否合法
  1. 解压ipa。
  2. 取出embedded.mobileprovision,通过签名校验是否被篡改过。
    1. 其中有几个证书的公钥,其中开发证书和发布证书用于校验签名。
    2. BundleId。
    3. 授权列表。
  3. 校验所有文件的签名,包括Frameworks。
  4. 比对Info.plist里面的BundleId是否符合embedded.mobileprovision文件中的。

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

数字签名

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

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

数字证书

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

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

iOS证书申请和打包

流程图

图片 9

证书申请

开发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文件的结构:

图片 10

将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重新签名的流程

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

图片 11

解压ipa。

如果mobileprovision需要替换,替换。

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

对xxx.app签名。

重新打包。

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

解压ipa。

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

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

BundleId。

授权列表。

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

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

版权声明:本文由大奖888-www.88pt88.com-大奖888官网登录发布于大奖888官网登录,转载请注明出处:iOS开发中的数字证书是Apple,而且加密密钥和解密