ios安全团队对ios安全的认识

http://images.apple.com/iphone/business/docs/iOS_Security_Oct12.pdf

转载请帖http://blog.csdn.net/u011069813/article/details/9256233

苹果的3.5寸黄金分割、用户最佳体验随着三星的大屏已经成为历史。jobs去世以后，苹果的创新也失去了灵魂。

最新发布的ios7相对于ios6在UI上有重大突破，用了IOS7以后，感觉清爽了很多，,从此腰不疼腿不酸了。

看这张图就知道他们的差别了。

 

但无论如何，ios在用户体验的一致性、安全方面都有值得学习的地方。搞游戏的都知道，要赚钱先得搞IOS。搞android，终端还没适配完毕，钱都花光了！

今天就介绍一下IOS的安全机制。

 先来一张系统安全架构，后续逐渐解释：

IOS内核来源于OS X，很多安全特性也由此借鉴。

1、安全启动

苹果的系统完整性校验主要包括：bootloaders, kernel, kernel extensions, and baseband firmware.
Boot ROM先启动，里面内置了Root CA public key，然后验证  Low-Level Bootloader (LLB) ，LLB是苹果签名的.  LLB 又去验货next-stage bootloader, iBoot, iboot验证kernel.

如果上述有验证的某个环节没通过，手机会显示 “Connect to iTunes” .越狱的朋友深有体会。其实就是进入了 recovery mode.。

如果Boot ROM 加载或者验证LLB都失败了，那就进入了 DFU (Device Firmware Upgrade) mode.

上述两种情况都需要求助于 iTunes 了。  这些模式等到后续介绍ios越狱详细介绍。

2、System Software Personalization

IOS最牛的地方就是通吃产业链，有漏洞及时发现，及时patch。有些爱越狱的同志升级以后发现不能装软件了（要支持正版哦）。。。。，就想回到过去，想降级（ios5.50-->ios2.50）！

试想想，人生能回到过去？重新来过吗？那些不能忘怀的校花？

System Software Personalization 就是对付降级的，降级就会导致原来的漏洞继续存在！

网上经常看到，有降级包吗？降级包下载！！！ 老版本已经被越狱，自然有大神制作包。那么如何阻止这些包被屌丝安装呢？

 这其中itune扮演了很屌的角色！安装或者更新时， iTunes (如果你是wifi甚至你不差钱通过3G那就是设备了) 会连接到 Apple installation authorization server (gs.apple.com) ，会加密发送你要更新的内容信息（切记肯定是摘要之类的信息）（比如 LLB, iBoot, the kernel, and OS image), 一个防止重放攻击的随机数、 设备unique ID (ECID). 服务器检查一下你要升级那些（服务器记录了你终端的状态信息。。。这点也很可怕哦），如果发现数据库里面记录的这部ecid终端原来是io6，现在想升级成ios7.说明是个良民啊。准奏！那就签个名返回吧，准许安装，当然安装包肯定是要验证签名的。

因此这个功能System Software Personalization指的就是the ECID “personalizes。每个终端目前啥版本那都是苹果登记注册的，休想降级！

一个防止重放攻击的随机数防止你以后复用服务器的响应。比如你这次升级到ios7了，下次升级到ios8了，你可能想从ios8回复到ios7，ios7的服务器回复数据就可以让你回复到ios7.

3、代码签名

    android的代码签名就不值得一提了，安装时验证一下，以后就不管了，无非升级时玩玩。 这存在很大的安全隐患，比如动态加载等。

  android还有代码动态修改的能力，这些细节都等老王的书里面看吧。

苹果的代码签名相比历史上出现的代码签名都牛叉的地方在于：

1）、价格高，99$,屌丝桑不起！开发啥恶意软件，门票都交不起！

2）、审核严格，没有三个月别想着审核通过，等不起。刚开发一个邪恶的，等审核通过了，漏洞已经补了。

3）、运行时代码签名检测  checks of all executable memory pages ，防止动态加载或者篡改！ 很厉害！！！

4）、苹果除了个人应用强制签名，统一电子商城入口外，也开放企业签名，咱们社会主义大企业内部可以签名使用，但也有一些不和谐的，，，私自用企业版签名发布软件乱发布的。。。。

 4、沙箱

 

应用都是“sandboxed，不能相互偷窥内存和文件。 每个应用都有自己唯一的目录。/var/mobile/Applications/[GUID]

第三方应用的用户身份都是mobile。

想申请一些特殊能力就得申请，现在的系统都差不多，无非就是能申请的范围多与少。

等会几个例子：

但这个申请的能力是代码签名的，是不能改变的。

an app and allow authentication beyond runtime factors like unix user ID.  这句话值得大家去深入理解。这就是ios sandbox的精髓所在！那就是传统的DAC+自定义的MAC机制。

ios的沙箱设计很经典，内部代号“Seatbelt”。

For XNU systems, implemented as a TrustedBSD policy module，Runtime configurable, per-process access control policy。

其实就是实现了强制访问控制MAC，可以实现每个进程的策略，比如那个进程能访问那个文件、进程、外设等。

这其实就是现在的SEAndroid。只不过MAC的核心是policy，为了满足各类应用的需求，policy不好设计，一般就是给一个缺省的。

但其内核很强大的，可以扩展，比如：

fluffy:tmp dion$ sandbox-exec -n no-internet /bin/sh 禁用网络了

sh-3.2$ file /etc/passwd
/etc/passwd: ASCII English text
sh-3.2$ ping www.eff.org
PING eff.org (64.147.188.3): 56 data bytes
ping: sendto: Operation not permitted

sandbox看下图，MAC的核心在内核完成，其它各层配合策略为主。

 

比如下列的策略：

一些系统自带的沙箱配置文件：

总之，ios的沙箱非常强大，随时准备爆发，android还在尝试selinux的机制，ios都已经内置了！

 

 

 

 

ios提供一个缺省的 sandbox，剩下的交由开发者和用户了。 SEAndroid也是这样的思路，他也想把策略交给用户，可用户不懂如何配置策略让终端更安全，所以SEAndroid的市场在企业领域，那儿有个管理员，他应该懂！

ios的应用手段也比较匮乏，主要是：custom URL schemes、 shared keychain access groups.

举例：引：http://blog.csdn.net/cloud_zero/article/details/6054040

iPhone上URL Schemes的作用为应用程序提供了一个其他应用程序或者safari可以启动他的方法.就像Android上intent一样.只不过Intent的功能要比URL Schemes强很多.

原理很简单,首先Schemes是在你的应用程序的info.plist里面定义的,在安装应用程序后.应用程序可以解析你的info.plist,如果检测到CFBundleURLTypes,会将相应Scheme注册到系统里面。如果有应用程序通过[[UIApplication sharedApplication] openURL:url]打开了safari或者直接在safari里面输入URL.系统会检测URL,然后对照已经注册的scheme来启动相应的应用程序.比较常见的scheme有http,mailto,tel,sms.

url可能带来漏洞，比如：

– URL Scheme allows to edit or delete data without user permission

  Ex: Skype URL Handler Dial Arbitrary Number

  <iframesrc="skype://14085555555?call">

 

Address space layout randomization (ASLR)、ARM’s Execute Never (XN) feature我就不多说啦，微软这么多年一直都在这方面努力。

XN ：可写可执行的一定严格控制， The kernel checks for the presence of the Apple-only “dynamic-codesigning” entitlement.即使如此, only a single mmap call can be made to request an executable and writable page, which is given a randomized address. Safari uses this functionality for its JavaScript JIT compiler。逼不得已才开放！

ROP等攻击一直在持续。

4、++API控制

   ios基本把危险的API全部干掉了！剩下的都是运行时提示。

5、数据加密

 这可是ios最大的亮点。其他系统还在学习中！

 1）、硬件加密引擎内置，内置 AES engine, SHA-1，说实话，没有硬件保存密钥、完成加密运算。数据加密就已经失去了8成安全！苹果的加密引擎DMA path between the flash storage and main system memory。大数据加密效率非常重要。

2）、内置两个初始密钥 unique ID (UID) and a device group ID (GID) are AES 256-bit keys。这两个东西谁都无法读写，除了加密引擎。

The UID是每个设备独有的 and  not recorded by Apple or any of its suppliers.（革命形势啊！）

The GID 是一类芯片一个，比如A5的芯片内置的GID密钥都一样。

由于UID是每个设备独有的，而且它是整个ios系统密钥树的最顶层，因此，数据就绑定了设备，flash、memory离开了根，就无法解密.

加密除了防止艳照门，被人偷窥外。由于flash技术的特点：wear-leveling 。删除数据很困难哦。既然加密了，就容易多了，只需删除密钥即可。

为此， iOS 提供一个Effaceable Storage. accesses the underlying storage technology (for example, NAND) to directly address and erase a small number of blocks at a very low level.。以便wear-leveling删除太麻烦。

6、文件加密

文件加密和数据保护按理是一个话题，但排版不方便，在起一个节吧。

文件加密还得考虑锁屏等环节。那些数据必须开启锁屏才能解密？要不然锁屏就成了摆设。

 

更详细的图：

 

 

 

简单说明：

Key 0x835 = AES_encrypt (UID, 0101..01)。。也是UID直接计算出来的，也是和设备绑定的。

data partition 每个文件创建时，Data Protection会创建一个256-bit key (“per-file” key) ，然后使用这个密钥借助硬件 AES engine。加密模式通常是AES CBC mode（不懂的看密码学）. 既然是CBC自然需要IV，IV怎么来， 用文件的块偏移计算LFSR（ linear feedback shift register (LFSR) calculated with the block offset into the file）, IIV也是加密存储，encrypted with the SHA-1 hash of the per-file key.

per-file key是实际用来加密文件的，那它也得被保护啊。这就得分好几种条件了。
然后，加密的 per-file key is stored in the file’s metadata。.

然后file’s metadata又被加密了，The metadata of all files in the file system are encrypted with a random key, which is created when iOS is first installed or when the device is wiped by a user. The file system key is stored in Effaceable Storage. 其实这个加密价值不大。主要是为了销毁密钥方便。ios界面上操作 “Erase all content and settings” option,就是干掉了这个密钥。最终无法获得加密的per-file key。per-file key到底被谁加密，环境很多。根据不同的环境使用不用的 class key。 class key 又被 hardware UID 保护，有些情况下是通过user’s passcode. 如果你的数据相关联pin，那就得靠他。这非常重要！！！

多层密钥架构还有一个好处，就是对加密的内容更换密钥，无需重新加解密数据，那样效率很低，而只需更换加密key。

 

 现在上面的图你看懂了吗？后面我把classkey分类再说明一下。

1）Complete Protection
(NSFileProtectionComplete):

class key来自于passcode and the device UID杂交而成。. 比如 locks a device (10 seconds, if the Require Password setting is Immediately),解密后的class key is discarded，要想解密数据就得重新输入pin吗。比如存储的邮件就是这种保护机制。
2）Protected Unless Open
(NSFileProtectionCompleteUnlessOpen):

后台下载的东西是群众需要的！但这时候想加密，不能让人民群众输入pin码啊，那赶脚就太差了，咋整！有办法！

先用椭圆曲线密钥算法ECDH 产生一对密钥。用刚刚产生的 file’s private key 和the Protected Unless Open class public key（系统产生的）计算一个共享密钥, 他对应的私钥被user’s passcode and the device UID保护。从这儿就管理了pin码！然后实际用来加密文件的密钥就被这个共享密钥的hash 加密并且存储在文件metadata ，同时存储ecc产生的 file’s public key，然后销毁ECC私钥。打开文件时，共享密钥可以由 the Protected Unless Open class’s private key（它靠pin和uid计算）计算。计算出 hash 就可以解密 the per-file key, 然后解密文件。

3）Protected Until First User Authentication
和第一种一样，, 唯一的区别就是锁屏后不清除内存密钥。the decrypted class key is not removed from memory when the device is locked.
4)No Protection
(NSFileProtectionNone):  class key 被UID保护, 这种加密主要是擦除方便。因为所有用来计算密钥的信息都在终端上保存，如果一个越狱后的木马，那就。。。

The iOS Software Development Kit (SDK) 提供Data Protection供您选择！Data Protection is available for file and database APIs, including NSFileManager, CoreData, NSData, and SQLite.

 

6、+++小数据加密

得加密啊！

刚才谈到的是文件加密，在加密层次上属于文件系统透明加密，如果更底层，可以给予存储加密，比如android目前的加密机制，可以实现全盘加密、分区加密等。对应分区部署的应用和数据透明加密。

现在谈一下小数据加密，比如你想保存你的口令，各种账户的密码等。

这就是ios Keychain Data Protection

keychain 的存在实体是数据库sqllite。他通过上文提到的 No Protection class保护。

既然keychain里面存储了各类应用的敏感数据，securityd daemon 管理这些数据。

Keychain access APIs 会调用 the securityd framework,该框架检测应用是否申请  “keychain-access-groups” and the “application-identifier” entitlement。通常keychain是绑定与创建的进程的，但也可以通过 access groups 对应用共享。如何共享，只有给同一个开发者。这通过iOS Developer Program中配置access group完成。开发的同志们自己去体验一下。至于这些数据如何加密的，和上述的文件加密基本类似。

 

 

每个 keychain class都有一个组成：  “This device only” , 他主要是备份时使用，这个数据被UID保护，也就是通过UID和设备绑定，防止恢复到另一个屌丝的手机里面。

那些数据可以啥时候可用，苹果替大家想好了，比如VPN证书总不能因为lock了歇了吧！比如他不能离开屌丝1的终端吧，如下图。

 

 

 6、++++keybag

前文多次提到了class key，他们在哪儿保存呢？就是keybag.

 keybags有4类: System, Backup, Escrow,and iCloud Backup.

其实就把几类class key分类了一下，我就不详细介绍了，煮的玉米熟了，该吃了。

  

 7、passcode

口令复杂度大家都可以自行设置，也可以通过MDM远程配置。

由于上文提到数据的加密有些是关联pin码的，所以这个pin码很关键。

android的pin码经常被人dump，后续虽然加了salt，但salt也是本地存储的。。。。所以认人蹂躏！

ios不同，他有谁都看不见的UID，也就是说最终的加密密钥是pin和UID共同计算的结果!!虽然数据无法直接提取出来，!对暴力破解加大了难度！但如果root了，搞一个程序运行在ios上，，，，虽然不知道uid，但uid一直客观存在哦。。。也是有风险的，所以一定要强口令。

 8、传输加密

TLS、DTLS都支持。

High-level APIs (such as CFNetwork) make it easy for developers to adopt TLS in their apps, while low-level APIs (SecureTransport) provide fine-grained control.

各类VPN支持，ipsec、、ssl、pptp

9、wifi

支持EAP-TLS, EAP-TTLS, EAP-FAST,EAP-SIM, PEAPv0, PEAPv1, and LEAP.

10、企业管理

1）口令类

• Allow simple value
• Require alphanumeric value
• Minimum passcode length
• Minimum number of complex characters
• Maximum passcode age
• Passcode history
• Auto-lock timeout
• Grace period for device lock
• Maximum number of failed attempts

2）配置类

Passcode policies
• Restrictions on device features (disabling the camera, for example)
• Wi-Fi settings
• VPN settings
• Email server settings
• Exchange settings
• LDAP directory service settings
• CalDAV calendar service settings
• Web clips
• Credentials and keys
• Advanced cellular network settings

 

Configuration profiles可以部署后无法删除，太霸道！凭啥企业配置了，不让我删除！！也可以在输入pin码后删除。

3）设备使用管理

• Allow app installs
• Allow use of camera
• Allow FaceTime
• Allow screen capture
• Allow voice dialing
• Allow automatic sync while roaming
• Allow in-app purchases
• Force user to enter store password for all purchases
• Allow multiplayer gaming
• Allow adding Game Center Friends
• Allow Siri

Allow Siri while device is locked
• Allow use of YouTube
• Allow use of iTunes Store
• Allow use of Safari
• Enable Safari autofill
• Force Fraudulent Website Warning
• Enable JavaScript
• Block pop-ups
• Accept cookies
• Allow iCloud backup
• Allow iCloud document sync
• Allow Photo Stream
• Allow diagnostics to be sent to Apple
• Allow user to accept untrusted TLS certificates
• Force encrypted backups
• Restrict media by content rating