模拟Airtags通过Apple的Findmy网络上传任意数据

它可以通过发送查找我的bly向附近的Apple设备上传到附近的Apple设备来上传来自非互联网连接的设备的任意数据

我们发布了一个ESP32固件，该固件将MicoController转换为（上载）调制解调器，以及用于检索，解码和显示上传的数据的麦斯科斯州应用程序：https://github.com/positive-security/send-my

固有的隐私和以安全为重点设计的查找我的离线查找系统，似乎不太可能完全防止这种误用

随着苹果公司的最近发布＆＃39;我很奇怪，无论是否找到我的离线查找网络就可以（ab），用于从未连接到WiFi或移动互联网的设备上传到Internet 。数据将通过蓝牙低能量广播，并由附近的Apple设备拾取，即它们连接到Internet后，将数据转发到Apple服务器，其中可以从稍后从中检索。在不受控制的环境中，小传感器可以采用这种技术，以避免移动互联网的成本和功耗。它对从iPhone用户偶尔访问的法拉第屏蔽网站中的抵消数据也可能很有趣。

从理论上讲，这应该是可能的：如果您可以模拟两个Airtags，则可以通过在特定时间点仅激活两个空中信料中的一个仅激活数据来编码数据。然后，接收设备可以检查哪些AirtAg在什么时候激活并将其解码回原始数据。然而，这种方案似乎非常不可靠，并且在现实世界的情况下可能无法使用，因为它非常低的带宽（特别是由于每个Apple ID诸如16个Airtags的限制，它似乎数据传输可能仅限于每小时几个比特）。

因此，该想法的可行性取决于系统＆＃39; S的设计和实现。事实证明，在离线寻找机制的设计中的安全和隐私决策使我们的＆＃34;用例＆＃34;非常有效，几乎不可能保护。

值得庆幸的是，该协议已经被一组TU DAMSTADT设计了一组，该论文＆＃34;谁能找到我的设备？＆＃34;在2021年3月并发布了一个名为OpenHaystack的概念验证开源实现，这允许您创建由Apple＆＃39查找我的网络跟踪的自己的配件。对团队的巨大学分！他们的工作使得这项可能是我们的PoC固件和Mac应用程序都基于Openhaystack。

当使用Apple设备划分Airtag时，生成椭圆曲线密钥对，并且将公钥被推到Airtag（以及共享秘密以生成滚动公钥）

每2秒，Airtag向公钥作为内容发送蓝牙低能量广播（使用先前共享的秘密确定每15分钟）

附近的iPhone，MacBooks等。认识到查找我的广播，检索其当前位置，使用广播公钥（使用ECIES）加密位置并上传加密位置报告

在设备搜索期间，配对的所有者设备生成滚动公共键列表，即Airtag在最后几天使用的滚动公钥并查询其SHA256哈希的Apple服务。 Apple后端返回所请求密钥ID的加密位置报告

然而，最有趣的是我们，Apple不知道哪个公共钥匙属于您的Airtag，因此为您提供了哪些位置报告。这意味着要为特定密钥ID请求定位报告的端点不会执行任何授权（但需要使用任何Apple ID进行身份验证以访问端点）。

安全性仅在于位置报告的加密：该位置只能用正确的私钥解密，这些密钥是不可行的，蛮力并仅存储在配对的所有者设备上。

从这看起来我们可以用来编码数据的唯一领域是广播的EC公钥（例如，我们可以影响GPS坐标，因为查找设备添加的GPS坐标）。

对于下一节，让＆＃39;将Apple后端视为共享的，使用SHA256哈希为键，并将加密位置报告为价值，具有基本操作：

我们可以通过广播相应的公钥将位置报告添加到特定的SHA256哈希

我猜你已经可以看到这是何处：我们可以在共享键值存储中设置任意位，并再次查询它们。如果发件人和接收方都同意编码方案，我们可以传输任意数据。

我开始构建一个调制解调器，通过串行接口拍摄消息，然后在循环中发送此数据，直到收到新消息。为了确保我们可以区分A＆＃34; 0＆＃34; - 从未命令位进行分辨，我们将根据比特值播放不同的公钥，并将在接收方面查询两种可能的公钥。

何时或是否在所有特定广播何时或是否在作为位置报告中上传到Apple后端。这是因为某些数据包可能无法达到任何Apple设备，并且查找设备可以在接收广播和上传位置报告之间具有高度可变的延迟，例如，取决于其上游连接或电源模式。这意味着我们的数据编码必须独立于接收位置报告的排序，并且能够在某些位完全缺少时恢复部分数据流。为此，我决定将每次广播的单一数据编码以及指示正在设置的消息的哪个位。其他邮件和调制解调器ID允许系统为多个消息和多个用户重用。

所以在发送特定位时，我们创建了表单和＃34的28字节数组; [4b位索引] [4b message id] [4b modem id] [填充0s ...] [bit]＆＃34 ;，将此视为公钥并将BLE广告发送到例如广播信息＆＃34;消息0的位0是1＆＃34;

要发送完整消息，程序只需循环其位，并使用编码其索引和值的公钥向每个位发送一个广告。

当获取数据时，接收应用程序将生成相同的28字节阵列（可能位值0和1），并使用SHA256哈希查询Apple服务。公钥＆＃34;只有两个密钥ID中的一个应该具有附加位置报告，然后可以解释（例如，索引0等于1的位。

注意：而不是每条消息仅传输一点，而不是每条消息，我们也可以是例如。通过设置公钥的最后8位发送完整字节。虽然这会增加发送带宽，在接收方面，我们现在需要请求255个不同的密钥ID来获取/＆＃34;蛮力＆＃34;一个字节（与16个密钥ID相比它＆＃39;逐位编码时）。

对于发送侧，我选择了ESP32，因为它是一个非常常见和低成本的微控制器（在快速测试中，它可以比例如，基于Linux的覆盆子Pi更快地改变其BT MAC地址。在启动时，基于OpenHaystack的固件广播了硬编码的默认消息，然后在循环中播放的任何新数据的串行接口侦听，直到接收到新消息。广播公钥实际上意味着将其拆分并编码蓝牙MAC地址中的前6个字节（前两位除了蓝牙标准需要设置为1）。您可以在Tu Darmstadt纸中查看第6.2节，了解有关此黑色编码的更多详细信息。

我向我的有效载荷添加了一个静态前缀，无法使用BT规范遇到问题，并且还包括公钥的前6个字节中的递增位索引，从而导致每个传输位用于每个传输位的不同BT MAC地址案例存在一些基于MAC地址的速率限制堆栈中的某个位置。

MAC应用程序还基于OpenHaystack，并使用相同的Applemail插件技巧将正确的经过身份验证的位置检索请求发送到Apple后端。提示用户4字节调制解调器ID（闪烁ESP固件时可以设置），之后应用程序将自动获取，解码和显示具有ID的消息0.之后用户可以获取其他消息或更改调制解调器。

一段时间（通过查询256密钥ID），在没有报告的情况下获取16个字节（128位），直到没有找到报告（对于完整字节）。

已经实现了发送和接收侧，我通过广播和尝试接收32位值来执行第一次测试。几分钟后，我可以检索32位中的23个，每个人都是明确的和〜100的位置报告，但没有报告剩余的9位。

我怀疑一些生成的公钥被附近的Apple设备拒绝在ECIES加密中作为无效公钥，并且可以通过尝试将每个生成的有效载荷作为P224曲线上的SEC1编码的公钥导入其中的每个生成的有效载荷来快速确认。 Python＆＃39; s fastecdsa：对于我找不到位置报告的每个位，微控制器已播放一个公钥，它在FastEcdsa键导入期间抛出InvalidSec1PublicKey异常。

秒码公钥通常也有一个＆＃34;标志＆＃34;定义特定x坐标的两个可能的y坐标中的哪两个坐标的位。该位对公钥没有播放和无关，＆＃39;有效性

在对压缩公钥的解码期间，使用固定曲线参数计算相应的Y坐标并测试有效性。这是测试某些生成的公钥的测试。您可以检查第3.2.2节＆＃34;验证椭圆曲线公钥＆＃34;更多细节：

在广播有效载荷之前，请检查其所代表的EC点是否实际上适用于所使用的曲线。如果没有，请递增柜台，直到找到有效的公钥。此过程是确定性的，并且可以在查询密钥ID之前类似地通过检索应用程序执行脱机

将有效载荷解释为私钥（而不是公钥）。虽然压缩的28字节公钥被解释为曲线上的潜在点的x坐标，但是在EC点/标量乘法中解释为标量的28字节私钥，从而总是导致曲线上有效点（公钥）

第二个选项具有每个接收位的优势，我们也能够解密位置报告以找出它接收的位置，但它需要更多的处理。在实现此选项的同时，我发现由于EC乘法的错误，对于使用的UECC库的错误，对于某些私钥，ESP将计算不同的公钥，而不是在Mac和Python＆＃39上的Boringssl（意外差异模糊？ ）。这些公钥甚至被UECC＆＃39;自己的UECC_VALID_PUBLIC_KEY（）函数视为无效。因此，我选择与此poc的选项1一起使用。

通过实施的公钥有效性检查，一切完美无瑕。虽然我没有做出广泛的性能测试和测量，但这里有一些估计值：

微控制器上的发送速率是目前〜3个字节/秒。可以实现更高的速度。只需通过缓存编码结果或通过每个广告编码一个字节

在我的测试中，接收率受到慢MAC硬件的限制。在一个请求中检索16个字节需要〜5秒

延迟通常在1到60分钟之间，具体取决于周围的设备和其他随机因子。以下图形显示了公钥广播与上载的相应位置报告之间的延迟分配。但是，请注意，这是每个位置报告上传，而不直接代表直到可以下载广播数据的时间（已经从任何附近的Apple设备提供的第一个位置报告）

虽然我大多是好奇的，但是是否有可能，我会盖住最常见的用例，以上上传传感器读数或没有宽带调制解调器，SIM卡，数据计划或WiFi连接的IoT设备的任何数据。亚马逊运行类似的网络，称为Sidewalk，使用回声器件可能会很好地需求。由于查找设备缓存接收广播，直到它们具有互联网连接，因此传感器甚至可以从没有移动覆盖的区域发送数据，只要人们通过该区域即可。

在高安全性网络的世界中，在结合激光器和扫描仪似乎是一种值得注意的技术来桥接气球，游客＆＃39; S Apple设备也可能成为可行的中介机构，以防止某些防弹系统或法拉第笼中的数据。

它似乎也可以使用离线查找协议来耗尽附近的iPhone＆＃39;移动数据计划。通过从查找设备的位置报告的位置报告（由于1个字节计数为1的255报告/提交），并且每个报告超过100字节，广播许多唯一的公钥应导致发送的移动流量放大电话。虽然我哈文＆＃39; t注意到所发出的位置报告数量的任何速率限制，我也没有测试过多少数据消耗。

如上所述，如果他们想要的情况下，苹果将努力抵御这种滥用。

Apple设计了数据经济原则的系统。他们无法读取未加密的地点，不知道哪个公共钥匙属于您的Airtag，甚至哪个公钥一定的加密位置报告属于（因为它们只收到公钥＆＃39; s sha256哈希）。

在这种光明中，每个苹果ID的16个机动标记的规定限制似乎很有趣，至于我，它似乎似乎苹果公司目前不能强制执行这一点。

然而，系统的进一步硬化可能为例如。在以下两个领域是可能的：

识别BLE广告。目前，Finder设备不能区分例如区分。基于Openhaystack的Airtag和克隆，从而允许欺骗许多千种非现有的空中信料来编码和传输数据。通常人们会考虑签名公钥，但是，通过BLE广告大小已经完全用尽，空中电源低功耗而未连接到互联网，并且广播键不断旋转，这呈现出相当挑战。

速率限制定位报告检索。虽然Apple不知道所请求的密钥ID是否属于请求用户＆＃39; s airtag，但它们可以缓存所请求的密钥ID，并确保每15分钟和Apple ID查询16个新密钥ID（允许之后在最后几天期间初始搜索的数字更高）。虽然更容易实现，但通过循环通过多个免费Apple IDS进行数据检索，可以绕过这种缓解。

在这个博客文章中，我们已经回答了初始问题，无论是＆＃39; s吗，可以使用其他人＆＃39; s苹果设备上传任意数据，清晰的是。

ESP32调制解调器固件和麦斯科斯数据检索应用程序是实现的，可在Github上获得，用于其他人进行实验。

请注意，这是一个PoC实现和＆＃34;协议＆＃34; 本身既不加密也不是经过身份验证的。 示例性的是，只需输入其ID，您可以探索调制解调器ID 0x42424242的数据（也许在此期间有人也表明了协议＆＃39;缺乏认证😉）。 最终注意事项：在撰写此博客文章时，我注意到A＆＃34;状态＆＃34; 包含在BLE广告中并显然使用的字节。 作为电池电平指示灯。 结合确定地生成的旋转私钥，这可能是每个广告一个字节的数据泄漏数据，但我没有测试这种方法。