随着存储在云端的宝贵数据越来越多，对这些数据进行稳健的保护就愈发重要。围绕 iCloud 等云数据服务采取强有力的安全措施，对所有人都有益：终端用户、Apple 这样的云服务提供商，以及 Reincubate 这样的生态平台。
保护这些数据的机制有多种形式，Apple 在落实这些机制方面一直表现良好。本文探讨他们以及 Reincubate 团队一直在使用的多种技术。
尽可能少存储
首先，_少存储而不是多存储_是有回报的。有些例子中，数据从未存储在 iCloud 中，比如“照片”中的人脸识别数据就不会存储在 iCloud 照片图库中，而是缓存在本地。Apple 的 HealthKit、HomeKit 和触控 ID 产生的数据也是类似的处理方式，Android 的锁屏人脸识别数据同样如此。当然，这往往是在便利性与在设备之间同步这些数据的价值之间所做的取舍。有些系统采取部分存储的方式。例如，iMessage 在云端只存储有限的内容，其他数据则依赖设备之间直接同步。
Telegram 或 WhatsApp 等安全通讯系统采用的是完全不同的方式。由于它们的服务器上没有存储任何数据（或者至少存得不多），设备的任何备份中都必须包含丰富的数据，用户才能真正有意义地备份和恢复。从某种意义上说，为了保证安全，这些应用厂商撒手不管这些数据的管理，把它交给终端用户，由用户选择在本地还是在云端备份自己的设备。
因此存在两个极端，可以拿 WhatsApp 与 Facebook Messenger 做对比：前者云端几乎什么都没有，一切都在备份中；后者不会在设备备份中存储任何内容，因为这些内容在云端随时可取，而且必须如此，Facebook 才能提供它的网页界面。
这里没有正确的解决方案，但值得思考：使用一款由应用托管这些数据的应用，就要求应用厂商安全地管理这些数据，而用户往往不清楚究竟存储了什么、又是如何存储的。使用一款不集中存储数据的应用，则意味着终端用户必须自己为备份数据的安全负责，除非他们把备份交给所用平台的云来存储，就像 iCloud 备份和 Google 的 Android 7.0 及以上版本设备备份那样。
有趣的是，如下图所示，有些应用厂商同时占据了这一立场的两个极端。Snapchat 应用几乎把所有数据都存储在云端，而该应用的实体延伸产品 Spectacles 则把所有数据都存储在设备本地。
应用数据安全的不同做法
虽然没有大范围推出，但 Snapchat Spectacles 相当不安全：只要按住“snap”按钮七秒钟，黑客就可以把它们与新手机配对，并获取合法所有者存储在其中的所有未加密的 snap。这与 Apple Watch 所采用的安全原则形成了鲜明对比。
强加密
这就引出了第二项关键技术：强加密，理想情况下还应不完整地存储密钥。如果数据被认为过于敏感，不适合以设备损毁或更换后仍可访问的方式备份，还可以采用其他技术。Facebook 的“秘密对话”功能要求使用特定设备，并利用硬件标识符对内容加密。如果设备丢失，这些内容实际上就无法找回了。
有些系统采用类似的技术，可以创建_设备专属令牌_，以确保同一时间只有有限数量的设备能够访问内容。Snapchat 和 WhatsApp 各自使用了这种方式的某种变体。在设备上登录 Snapchat 时，会创建一个令牌，由 Snapchat 的服务器和设备共享。如果同一用户登录另一台设备，就会创建一个新令牌，取代云端原来的令牌，并迫使第一台设备退出登录，因为它无法解密任何传入的消息。这项技术用于不安全的系统时有一个明显的漏洞，那就是令牌可以被复制并在其他地方使用。如果需要一个理由来说明为什么使用已 root 的 Android 或已越狱的 iOS 设备是个糟糕的主意，这就是理由，这也解释了为什么 Snapchat 短期内不太可能推出网页版客户端。
丢失秘密的 Facebook 信息是一回事，但有些数据对其所有者来说既高度敏感，又极具价值。这看起来有违直觉，但如果数据的个人价值足够大，它往往会以这样一种方式存储：有许多潜在的途径可以解密或恢复它。这是用安全性换取更低的不便。例如，iCloud 和 Google 账户关联着大量数据，其中两者都包含某种形式的分布式云端钥匙串，存储着用户的所有密码。不仅如此，Google 通过 OAuth 把自己的账户推广为其他网站的身份验证机制，这意味着永久失去对此类账户的访问权限将是一枚难以下咽的苦果。
鉴于这些账户被认为过于宝贵，不能轻易冒着永久丢失的风险，因此采用了一种折中的方案：数据存储在云端，但用只有用户自己保管的令牌或密码加密，而这个令牌或密码并不存储。比如，这就是为什么在全新安装的 Google Chrome 浏览器中登录时，云端存储的密码要等到在浏览器中输入第二个同步密码之后才可用。
分担加密的负担
Apple 的 Tim Cook 在安全问题上既认真又从根本上正确，就在去年，他还证明了他们对这项技术的信念：
For many years, we have used encryption to protect our customers’ personal data because we believe it’s the only way to keep their information safe. We have even put that data out of our own reach, because we believe the contents of your iPhone are none of our business.
— Tim Cook，出自“A Message to Our Customers”
除此之外，这还能帮助云服务提供商避免向政府机构披露完整的用户数据。如果他们被搜查令强制要求提供数据，也可以做到不直接暴露用户的数据，因为这些数据还需要进一步解密，而只有终端用户才持有解密所需的密钥。
有时，例如多重身份验证（MFA）、双重认证（2FA）或两步验证（2SV）的情况，这意味着额外的密钥只能发送到某台特定设备，或由该设备生成。银行和 VPN 常使用实体读卡器或安全种子生成器，它们属于基于时间的一次性密码生成器（OTP 或 TOTP）。Google 和 Apple 既提供简单的基于短信的 MFA，也提供完整的 2FA 系统，其中 Google 的采用 HOTP/OATH，而 Apple 的则是专有的。
当安全机构或执法机构（LEA）持有这些加密数据，却没有解密所需的终端用户密钥时，他们可以尝试暴力破解，用强大的机器把数据与自动猜测的密码逐一比对。在这方面，Apple 的 iOS 相比 Google 的 Android 有着巨大的优势：由于 Apple 严格掌控其设备中的硬件，他们能够设计出只有自家硬件才能快速执行、而台式电脑等其他设备执行起来很慢的加密技术。当 Reincubate 成为全球首家支持解密 10.2 数据的公司时，意义不仅在于公司率先弄懂了 10.2 的工作原理，更在于我们率先实现了对 Apple 这项巧妙技术的大规模快速解密。由于在常规硬件上每次解密尝试都要花费数秒，黑客或执法机构要进行暴力破解就变得不切实际。
通过隐匿实现安全
回顾这些技术时，不能不提 Apple 尤其擅长的一项：通过隐匿实现安全。他们不发布公开 API、详细文档，甚至很少谈论这些系统，从而避免让黑客留意到潜在的攻击途径。很长一段时间以来，反对隐匿的论点是，公开披露和开源会带来更好的安全结果，但那是在 2014 年之前，当时人们还没有发现 OpenSSL（几乎所有产品都在使用的一个关键的开源安全库）一直以来几乎都存在根本性的安全缺陷。
如果你想探讨如何处理应用数据或云端数据，或者有兴趣更深入地了解不同做法的内在机制，欢迎联系我们。
