苹果iCloud数据加密了吗？

自2011年iCloud正式进入iOS系统以来，苹果公司云服务iCloud数据安全问题就是业内一直关注的焦点。2016年9月，iCloud被爆存漏洞、明星私照遭泄露一事被炒的沸沸扬扬，尽管苹果先前指出，其云服务自己是安全的，一旦遭到泄露属于人为所致，但这个说法并未获得普遍承认。api

而随着苹果去年7月宣布在贵州省创建数据中心，并于今年2月28日正式将中国iCloud用户数据转由云上贵州运营，钥匙串一同被转移，关于iCloud用户数据安全性等一系列问题再次喧嚣尘上。
安全

而这一变化主要源于去年6月新网络安全法的正式实施。该《法》规定，全部与宽泛定义的国家安全问题有关的中国公民或地区数据，必须存储于国内的服务器上，并且云服务的运营方必须为本地企业。服务器

事实上，世界各国执法部门都向苹果公司提出了合法的数据获取需求，并得到了苹果公司的赞成。《金融时报》曾指出，美国法律规定，若是外国政府想获取储存在美国服务器上的该国公民数据，走完流程时间或将长达数年。网络

而对于国内的普通用户而言，这一作法将有益于提升访问连接的速度和稳定性，不会总是出现访问一个页面须要分钟级的问题。但在数据的安全性方面，却引起了诸多担心。除了国内咱们在社交平台上的讨论以外，国外的研究者们也有各自看法。架构

前不久，约翰霍普金斯大学教授、密码学家Matthew Green撰写的一篇文章“Apple in China: who holds the keys?”其中有些见解值得咱们阅读，在此，CSDN 摘编精要分享给你们。app

以下：iphone

近日苹果发布的一项公告，宣布了关于iCloud服务的变化：从今年2月28日起，苹果将把中国区用户的iCloud数据交由云上贵州公司负责运营。性能

中国方面，这一举措能够提升用户的网络性能，而苹果则表示，这一变化主要是因为中国区新的云服务法规。对这两种解释，Green认为都是正确的，但他却很难判断出另外一个问题：不管数据存储在何处，其安全性又如何？测试

根据苹果的答复：“苹果拥有强大的数据隐私与安全保护，咱们的系统不会有任何后门。”能够看出，若是苹果将用户数据存储在内地的服务器上，那就没法排除苹果以外也会拿到这些数据，并且可能根本不须要苹果的许可。ui

对此，就苹果iCloud数据加密问题，Green展开了一系列发问与思考。

苹果iCloud数据加密了吗？

然而，苹果iCloud数据是否加密，具体取决于iCloud的哪部分，以及如何定义“加密”。以下图所示：全部iCloud数据可能都通过了加密。但这个问题自己不够准确，换个方式问应该是：谁持有密钥？

Green提到，能够经过一个很是简单的思惟实验来肯定你（供应商）是否控制密钥，即“泥水坑测试”， 具体内容以下：

假设你在一个泥泞的水坑里滑倒，而后你的手机摔坏了，再而后事发忽然你脑中一片空白甚至忘记了密码。试问你还能找回iCloud的数据吗？若是能够，或在苹果支持的帮助下能够，那么证实控制密钥的人不是你。

除了一个特例，即下文他将要讨论的iCloud 钥匙串以外，iCloud服务没法经过该测试。这是由于大多数的苹果文件不是端对端加密的。事实上，这一点在苹果的iOS安全指南上写得很清楚，iOS会将加密文件的密钥发送给iCloud。

可是，iCloud并不彻底是苹果的服务。事实上，绝大多数的iCloud数据实际上并无存储在苹果公司。每次备份手机时，通过加密的数据直接传输到各种第三方云服务供应商，包括亚马逊、Google和微软等。

从iPhone进行iCloud备份时发出的HTTPS请求列表。底部的两个地址是Amazon和Google云服务“blob”存储

从隐私的角度来看[1]，这些服务仅仅做为“blob存储”，负责保存苹果客户上传的不可读加密数据文件。至少原则上来讲，苹果能够控制该数据的加密密钥，理想情况下应该保存在苹果专设的数据中心的服务器上[2]。

苹果将数据存储到哪里？

在他看来，在中国区全新的云商店提供的服务可能与AWS、Google或Microsoft所提供的服务彻底相同。也就是说，他们存储了加密的数据块，而这些数据在不联系iCloud美国总部的状况下没法破解。

可是，实际上，未经Cupertino许可就无权访问这些数据，所以，想要解决这些问题，就必需要求苹果将密钥和数据完整地存储到中国区的数据中心。

基于此，Green判断这两种解释是互相矛盾的，由于，前一个意味着苹果只是照常运营。后一个则意味着苹果可能大大削弱了系统的安全保护——至少对中国区用户来讲安全性下降了。

若是苹果为了遵照中国区法规，须要从根本上从新架构iCloud，但应该明确地说出作了什么改变。若是苹果没有明确说明，那么一种可能性是苹果会对iCloud基础架构的其余部分也进行相同的修改，却不公之于众。

不管如何，对于苹果来讲，至少应该澄清这一点。

那么iCloud钥匙串的状况如何？

上文中，iCloud有一个部分经过了泥水坑测试，那就是苹果的Cloud Key Vault，目前iCloud钥匙串用到了这项技术。这是一项保存应用程序的密码和密钥的特殊服务，它使用的保护级别比其余iCloud服务更强。这个模型能够很好地解释未来iCloud的其余部分如何实现。

简单来讲，CloudKey Vault使用了一种特殊的硬件来存储密钥，称之为“硬件安全模块”（HSM：HardwareSecurity Module）。此HSM是一个由苹果公司保管的物理设备。用户只有知道iCloud 钥匙串密码，才能访问本身的密钥。一般这个密码与iOS设备的PIN或密码相同。可是，若是任何人尝试屡次猜想此PIN码，HSM将删除该用户存储的密钥。

关键一点是，上面提到的“任何人”甚至包括苹果本身。简而言之：苹果公司设计了一个保存钥匙的保险库，即便他们也没法打开，只有客户能够拿到本身的钥匙。

因此，做者猜想：苹果已经以某种方式削弱了面向中国用户的iCloud Key Vault的版本，而这可能会引起关于苹果系统完整性更深层次的问题。

苹果该怎么办？

目前，苹果提供了大量有关安全系统的细节，如文件加密，iOS，iMessage，可是提供的iCloud加密等方面技术的细节却少之又少。尽管苹果能够访问iCloud备份数据，甚至能够将其交给执法机构，可是，苹果的钥匙串数据如何获得保护却不得而知。

在做者看来，苹果在安全方面的含糊其辞这一举动彷佛混淆了视听，使其难免质疑苹果对于技术安全方面的改进有着怎样的计划。例如，2016年的一篇文章（https://9to5mac.com/2016/02/25/apple-working-on-stronger-icloud-backup-encryption-and-iphone-security-to-counter-fbi-unlock-requests/）声称，苹果正在计划为iCloud提供更强大的总体加密。但关于这些计划是否已经废除，或者是否包括最新中文版的iCloud等等问题，其实不得而知。

在最后，Green也不得不认可：若是苹果不肯相信大众，不肯向你们解释系统的工做原理，那么也许也不该该相信他们。

注释：

[1] 这里须要注意的是，部分iCloud备份系统使用的是收敛加密（convergent encryption），也称为“消息锁加密”（message locked encryption）。这些系统中的设计思路是，文件加密密钥是经过文件自己的hash生成的。即便云存储服务商没有加密密钥，也能够测试用户是否拥有特定文件的副本。这可能会形成有问题。可是，从苹果的开发文档来看，这种攻击是否可行尚不清楚。

[2] 这只是一个猜想。苹果也可能把他们密钥存储外包给了第三方供应商，尽管这种作法并不明智。

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------