联邦调查局为什么要向苹果寻求帮助来解密iPhone？

#1 楼

我会尝试对此采取行动。从Apple的iOS安全指南中，我们了解到


文件系统中所有文件的元数据都使用随机密钥加密，该随机密钥是在首次安装iOS或当用户擦拭设备时。文件
系统密钥存储在Effaceable Storage中。由于该密钥存储在设备上，因此
不用于维护数据的机密性；


和


文件的内容使用每个文件的密钥加密，并用类密钥包装并存储在文件的元数据中，然后再使用文件系统密钥对其进行加密。
类密钥受硬件UID的保护，对于某些类，受用户的密码保护。
此层次结构提供了灵活性和性能。例如，更改文件的
类仅需要重新包装其每个文件的密钥，而更改密码只需重新包装
类密钥。


：通过物理上拥有设备，您应该可以轻松地获取文件系统密钥（取出SSD并从中读取密钥）。我们将其称为文件系统密钥$ K_ {FS} $。另外，每个文件$ f $使用每个文件密钥$ K_f $进行加密。要获得$ K_f $，我们需要有文件系统密钥（$ K_ {FS} $）和“类密钥”，我们将其称为类密钥$ K_C $。

因此，函数$ F_1 $给出了文件，文件系统密钥，类密钥为您提供了文件密钥。 $ K_f $ = $ F_1（f，K_ {FS}，K_C）$。这意味着FBI需要解密特定文件，它们需要：


$ f $✅
$ K_ {FS} $✅
$ K_C $❌

所以他们没有$ K_C $ afaik。是的，您通常如何获得该班级钥匙？该文档说，它受到“硬件UID”（$ K_ {UID} $）和（有时）用户密码$ K_P $的保护。 las，还有另一个函数$ F_2（K_ {UID}，K_P）$给出了硬件UID，并且（有时）密码返回了您的类密钥。
假设FBI可以轻易强行破解密码（$ K_P $），那么他们所需要的只是硬件UID（$ K_ {UID} $），但不幸的是，它们显然放在了芯片中，因此很难访问：


设备的唯一ID（UID）和设备组ID（GID）是AES 256位密钥，已融合到
（UID）或已编译（GID）到应用处理器和Secure Enclave中在
制造期间。没有软件或固件可以直接读取它们；他们只能看到
由专用AES引擎执行的加密或解密操作的结果，该引擎在硅片中使用UID或GID作为密钥来实现。此外，Secure Enclave的UID和GID只能由专用于Secure Enclave的AES引擎使用。
UID对于每个设备都是唯一的，并且Apple或其任何供应商均未记录。
GID对于一类设备中的所有处理器（例如，所有使用<苹果A8处理器），并用于非安全性至关重要的任务，例如在安装和还原过程中交付系统软件时。将这些密钥集成到芯片中有助于防止在AES引擎外部对其进行篡改，绕过或访问
。 UID和GID也无法通过JTAG或其他调试接口使用。

UID允许将数据以密码方式绑定到特定设备。例如，保护文件系统的密钥层次结构包含UID，因此，如果将存储芯片从一个设备物理地移动到另一个设备，则无法访问文件。 UID与设备上的其他任何标识符都不相关。


因此，如果我没看错的话，函数$ F_2 $似乎是在硬件中实现的，可以作为$ F_2'（K_P）$访问。请注意，$ F_2'$仅具有一个参数，即用户的密码。换句话说$ F_2'（K_P）= F_2（K_ {UID}，K_P）$，因此硬件UID由硬件自动提供。在非Secure Enclave iPhone（如5C）中，您可以使用自定义iOS版本对其进行暴力破解，使您可以随意使用$ F_2'$。在普通的iOS中，只有锁定屏幕可以运行$ F_2'$，并且可以防止您这样做而不会增加延迟（并可能最终擦除设备）。使用安全飞地iPhone（5S，6（+），6S（+））时，安全飞地会阻止您重复运行此功能。因此，即使iOS内核也无法立即运行$ F_2'$。

考虑到所讨论的iPhone似乎是5C，FBI似乎只需要Apple提供的特殊版本的iOS，允许他们使用自动提供的密码重复使用$ F_2'$而没有延迟。这应该给FBI 10000（假定4位数字的通行码）或1000000（假定6位数字的通行码）“类密钥”。然后，他们可以只尝试每个类密钥，并且其中一个将为它们提供数据。

与这个特定问题无关，但我认为这仍然很有趣：安全区域是否会进行任何更改这里？乍一看：显然是的，因为新的iOS版本不够好，因为Secure Enclave会通过强行强制输入密码来阻止您循环运行$ F_2'$。但是：安全保护区也运行某种固件，因此可以提高此限制，但可以更新安全保护区。到目前为止，我不清楚苹果是否可以在不擦除Secure Enclave中所有内容的情况下做到这一点。不同的来源主张不同的事情。本文涵盖了这一点。特别是，它引用了John Kelley的一条推文，该推文以前曾在Apple的Embedded Security中使用。他声称


[...]我不知道他们从何处得知更改SPE固件会破坏密钥。 SPE FW只是iOS系统部件上的签名Blob。换句话说：即使使用更新的iPhone，Apple仍可以将特殊固件部署到Secure Enclave（SPE），从而可以请FBI尽可能多地运行$ F_2'$。

我希望这会有所帮助。所有信息均取自《 iOS安全指南》及其对我的解释。恕我直言，FBI要求苹果，因为需要经常运行$ F_2'$而没有延迟，这样他们才可以蛮横地使用iPhone的代码。对于iPhone 5C，新版本的iOS应该就足够了，因为只有操作系统会阻止您这样做（您无法以编程方式访问$ F_2'$而没有特殊特权）。对于较新的iPhone，Secure Enclave确实可以防止这种情况。没有这个限制，FBI不能编译自己的黑版iOS，因为iPhone仅运行由Apple签名的代码，而FBI（可能）没有Apple的签名密钥。您知道或认为我误解了什么或弄错了什么。

#2 楼

加密密钥不仅仅来自密码。它也来自直接蚀刻到CPU芯片中的许多加密密钥。这些密钥无法在软件中读出-仅存在使用它们进行加密和解密的指令-并且通过检查硬件已故意使提取这些密钥变得困难。不是强行使用〜10位密码，而是强行使用256位密码密钥。即使对于现在地球上最老练的攻击者来说，这也是不可行的（或者至少是极其困难的）。

即使法院命令并未建议苹果提取密钥，以便FBI可以蛮力破解密码离线。 FBI仅要求Apple让他们通过扩展坞连接器提供iPhone密码，并禁用错误的密码延迟和软件中实现的自动擦除机制。

#3 楼

除非芯片被设计为允许您这样做，否则很难仅读出芯片上的每个存储元件，尤其是如果芯片被故意设计为阻碍您这样做的话。通用存储芯片显然很容易读出，因为它们被设计为可以从外部读出，但是复杂SoC内部的存储位置则是另一回事。

因此，您可以拥有软件已知的秘密材料。在设备上，但没有所述软件的配合就无法轻易读出。设备上的软件可以在工厂固定，也可以使用数字签名方案锁定更新。如果执行软件更新时未先解锁那些机密，则该软件可能被设计为销毁某些机密。密钥材料，那么制造商（或可以获取制造商签名密钥的人）可以生产出一个版本的软件，该版本无需进行过多检查即可发布密钥材料。访问代码的副本（可能同时包括源代码和二进制文件）可能有助于在上述代码中寻找可利用的漏洞。

#4 楼

跟进Brent Royal Gordon的回答：如果确实无法检索并只能使用硬件密钥，我认为Apple [1]可以通过使用密码来检索“ passcode”密钥来解决此问题（我仍称其为密码密钥，但这可以是其他一些随机密钥，并且密码用于通过硬件进行检索，并且在连续10次无效检索尝试后，让硬件本身（而非固件）擦除存储的密码密钥。

密码密钥和10次尝试限制以及启用/禁用可以存储在NVRAM的芯片内部。如果我没有丢失任何东西，则应该可以使用：



注意：修改NVRAM设置或设置新的密码密钥将需要当前密码，并且会具有与检索或使用密码密钥相同的限制。另外，“密码”实际上就是今天的密码的哈希。

1：真正的ARM，正如我读到的苹果公司的Secure Enclave是ARM TrustZone的定制版本。 br />