『iOS开发』iOS 签名机制

·  阅读 486

iOS 签名机制

对称加密(Symmetric Cryptography)

对称加密指的是发送端和接收端使用同一种算法对 明文(Plain Text) 进行 加密(Encrypt) 或对 密文(Cipher Text) 进行 解密(Decrypt)

symmetric_cryptography

发送方先将将要发送的 明文 消息使用加密算法加密为 密文,然后将 密文 通过网络发送至接收方。接收方在收到消息后,使用同一算法对 密文 内容进行解密,即将内容解密为 明文,这种情况下可以避免消息的直接明文传输,具有一定的安全性。加密解密使用的特定算法,我们一般称之为 密钥

常见的对称加密算法

  • DES
  • 3DES
  • AES

使用对称加密的方式进行消息传输需要解决密钥配送问题,发送方和接收方使用同一密钥进行加密解密,那在此之前,势必要保证发送和接收双方先拿到密钥,而在密钥的配送过程中,如果密钥被第三方窃取,那么此后双方发送的密文也能轻松被第三方解密。

非对称加密(Asymmetric Cryptography)

在非对称加密中,有 密钥对(Key Pair) 的概念,一个 密钥对公钥(Public Key)私钥(Private Key) 组成,私钥 不公开,由发送或者接收方自己持有,公钥 可公开,任何一方都可持有。

asymmetric_cryptography

消息发送方先使用接收方生成的密钥对中的公钥对明文进行加密,将加密后的密文通过网络发送至接收端,接收端收到密文后使用自己的私钥进行解密,最终将密文解密为明文。

常见的非对称加密算法

  • RSA

混合加密(Hybrid Cryptography)

非对称加密很好的解决了密钥配送问题,但这种加密方式相对于对称加密而言,加密解密速度较慢。针对此种情况,混合加密 方式应运而生,它结合了 对称加密非对称加密 两者的优势,是一种既能解决密钥配送问题,又能保证加密解密速度的新的加密方式

hybrid_cryptography

混合加密的实现方式:

消息发送方本地生成一个 随机密钥,使用随机密钥对明文进行加密,然后使用接收方 密钥对 中的 公钥 对本地生成的随机密钥进行加密,然后将使用随机密钥加密的密文和使用公钥加密后的随机密钥一同发送至接收方,接收方在收到密文和加密后的随机密钥后,先使用 私钥 对加密后的随机密钥进行解密,得到解密后的随机密钥,再使用这个随机密钥对密文进行解密,最终得到明文。后续接收双方就可以使用这个随机密钥进行加密通讯了,在 HTTPS 这种网络协议中就是使用这种混合加密方式实现的 安全套接字层(SSL/TLS)

数字签名

散列函数(Hash Function)

散列函数 是一种特殊的函数,又被称为 摘要函数哈希函数,通过它可以计算出消息的 散列值 (又叫消息摘要、哈希值或指纹)。相同的消息内容计算出来的散列值是相同的,不通的消息内容,尽管是很小的差别,计算出来的散列值都是有天壤之别的。散列值一般计算出来是一个固定长度的值,与消息的大小无关,1 bit 的消息和 1 TB 的消息计算出的散列值的长度是一样的。散列函数具有 单向性,一个原始消息经散列函数计算后得到散列值,但这个散列值不可再通过散列函数计算出原始的消息。

hash_function

常见的散列函数

  • MD4、MD5
  • SHA-1、SHA-2、SHA-3

散列函数一般用来校验数据是否被篡改。一个常见的例子是软件开发商一般将自己开发的软件经散列函数计算之后的散列值公开在自己的网站上,用户下载软件后可以通过散列函数计算散列值是否与软件厂商公布的散列值一致,以此来判断自己下载的是否是正版软件。另一个被广泛应用的用途是口令加密,想象一个登录场景,当用户在网站上注册一个账号时,是否会将用户的密码使用明文进行存储呢?答案显然是否定的,如果是用明文存储,一旦公司的数据库泄露,那所有用户的明文密码将会泄露,这种情况将是灾难性的。因此,业界一般采用的方式是使用散列函数,计算密码的散列值,再将散列值存入数据库中,下次用户登录时,只需要计算用户输入的密码的散列值与数据库中存储的散列值是否一致,从而判断用户输入的密码是否正确,因为散列函数的单向性,即使数据库泄露,也无法通过散列值反推出用户的密码。

数字签名(Digital Signature)

数字签名 是只有消息发送者才可以产生的无法伪造的,对消息真实性的一种证明。是一种结合和了 非对称加密 技术和 数字摘要 技术(即上文中提到的散列函数)的签名技术。

digital_signature

数字签名的实现方式:

发送方将待发送的消息使用 散列函数 计算出散列值,然后使用自己的 私钥散列值 进行加密,生成的即为 数字签名。然后将消息连同签名一并发送至接收端。接收端在接受到消息和签名后,首先使用 公钥数字签名 进行解密,得到散列值,然后对接收到的消息使用散列函数计算散列值,比较签名中的散列值和在接收端计算的散列值是否相等,来判断接收到的消息是否被篡改。

数字证书

数字签名 机制可以对发送的消息进行真实性认证,但是在网络通信的过程中,容易被劫持并篡改,耳熟能详的 中间人攻击(Man-in-the-middle attack,MITM) 就是其中的一种。

中间人攻击

所谓中间人攻击,是指攻击者与通讯的两端分别创建独立的联系,并交换其所收到的数据,使通讯的两端认为他们正在通过一个私密的连接与对方直接对话,但事实上整个会话都被攻击者完全控制。我们平常在开发中使用 Charles 抓包工具进行抓包的时候,其实这个过程就是中间人攻击。对于客户端,Charles 伪装成服务端,对于服务端,Charles 伪装成客户端,从而截获双方之间的通信讯息,并有可能进行篡改。

man_in_the_middle_attack

上图中描述了一次中间人攻击发生的过程:

  1. 首先发送者(Man)向接收者(Girl)发送请求发送者公钥的请求,消息被中间人(Mid Man)截获后,中间人伪装成发送者,同样向接收者发送了请求公钥的消息,消息接收者接收到请求之后,返回了自己的公钥,返回的信息再次被中间人截获,中间人将发送者的公钥保存下来,而将中间人自己的公钥返回给了发送者。
  2. 发送者在自以为拿到了接收者公钥,实际是中间人的公钥后,通过将要发送的消息 Today is a good day 通过散列计算生成消息摘要(Digist),并用自己的私钥进行签名,生成最后的签名信息(Signature),然后将消息和签名一同发送给了接收者。
  3. 此时中间人又截获了发送者的消息,中间人通过发送者的公钥(如何获取发送者的公钥?其实在步骤 1 中就可以拿到发送者的公钥,公钥是公开的),验证发送者的数字签名,认证有效,然后将消息 Today is a good day 篡改为了 Today is a bad day,同样通过中间人自己的私钥,生成数字签名,并将篡改后的消息和数字签名发送给了接收者 。
  4. 接收者收到来自中间人的消息,此时接收者并不知道消息并非来自发送者,而是被中间人进行了截获和篡改。使用中间人的公钥对数字签名进行验证,验证通过,最终得到 Today is a bad day 的消息。

中间人攻击出现的原因是接收双方在交换公钥的过程中,被第三方截获。从而导致消息传输的过程中,整个消息内容的控制权落到了中间人手中。怎样保证公钥在传输过程中不被篡改呢?

数字证书

数字证书(或公开密钥认证)是用来证明公钥拥有者身份的技术。公钥拥有者将自己的公钥发送给权威认证机构(CA),认证机构通过自己的私钥,对认证者的公钥进行数字签名,然后将公钥和数字签名作为数字证书。接收者拿到证书后就可以通过 CA 的公钥对证书进行验证,如果公钥和数字签名计算后的散列值一致,则认为证书有效,即公钥的拥有者身份得到确认,后续就可以通过公钥进行会话。其主要流程如下: digital_certification

iOS 签名机制

为了保证安装到用户手机上的 App 是未经篡改的,安全的,iOS 系统采用了签名机制,来保证应用的安全性,在应用编译完成后,将会使用开发设备 Mac 的私钥,对开发的 App 文件(包括可执行的二进制文件、图片资源、xib 等资源文件)进行数字签名。Mac 开发设备通过将自己的公钥上传至 Apple Developer 后台,通过苹果私钥对 Mac 开发设备的公钥进行数字签名并生成证书文件,再通过配置应用的 App ID、Devices(设备的 UUID)、以及权限文件(entitlements)将上述文件再通过 Apple 的私钥进行数字签名,最后和签名后的 APP 文件一起打包为一个 IPA 文件。详细流程如下:

1、上传 CSR 文件并生成证书文件

在钥匙串中选择 证书助理 > 从证书颁发机构请求证书

YhWFG7

填写邮箱和常用名称后选择存储到磁盘

jsSG2t

最后将生成一个 CertificateSigningRequest.certSigningRequest 文件

V57fNC

2、获得 ios_development.cer / ios_distribution.cer 证书文件

在苹果开发中心选择 Certificates、Identifiers & Profiles

8tAjo7

选择证书类型

ATbcPP
kxK0Gc
8UuHr5

制作完成之后即可下载 ios_development.cer / ios_distribution.cer 证书文件

3、注册 Device,添加 App ID,添加权限设置

添加 App ID

gWtTjI
lzRfhn
k35K6Z

添加设备,注册 Devices

zcwbGL
71ohj6

4、获得 *.mobileprovision 文件

选择要制作的描述文件类型

XN4Vat

选择 Bundle Identifier

WwN4Xq

选择对应证书

uw8SUz

添加 Devices

4U9Gxl

命名描述文件后即可下载

6PfZoh

下载的证书和描述文件双击即可安装,可用于真机测试和 App 包上架。

整体流程

ios_signature

当应用编译完成之后,就会通过开发设备的私钥对 App 文件进行数字签名,并将描述文件一起打入 IPA 安装包中,当安装到手机后,会验证设备的 UUID,App 的 Bundle ID 以及权限描述是否与 mobile provison 中的一致,若一致,则通过 Apple 的公钥验证证书文件并拿到开发设备的公钥,再去验证 App 的可执行文件及相关资源的完成性,若验证成功,则 App 可正常启动。

分类:
iOS
标签:
收藏成功!
已添加到「」, 点击更改