Showing Posts From

Mfi

MFI Software Token认证服务器规范解读

本文是对《Software Token Authentication Server Specification》这份Apple MFI认证文档的学习总结。通过深入理解这份文档，可以清晰地了解所有使用software token的Apple外设产品在MFI认证过程和产品的生成中，如何申请和管理Token以及如何在生产线上完成Token的写入和注册。 基于Software Token的MFI认证需求简介 对于Apple MFI认证的外设产品而言，以下三类产品可以支持使用Software Token（而不是MFI硬件加密芯片）来进行产品使用中的验证和鉴权： - HomeKit - AirPlay 2 audio - Find My network 当然，硬件上省掉了MFI加密芯片的费用，但是配件厂商如何向Apple申请这些需要内置在配件固件中的Token，以及如何妥善的管理好这些Token，则需要额外花费一些工夫。 对于这类基于Software Token的配件生产而言，Apple在规范文件中有如下要求： - 该型号产品在开发和生成之前必须要首先向Apple提交开案申请，Apple审核通过以后会给这个型号的产品发布一个PPID，有了PPID，配件厂商才能向Apple申请Token。 - 配件厂商必须要部署一台专门与Apple Server通信的服务器，用于向Apple Server通过预定义的HTTPS Restful API批量申请Token。配件厂商要有能力管理好这些申请到的token，并在产品量产的过程中把token通过产测软件写入到产品的固件中。每一台量产产品的token都不一样，配件厂商需要做好管理，生产完成后同样向Apple Server上报在产线上已经写入产品的token列表。 - 此外针对生产中尚未用完的token，配件厂商同样需要把这些未使用的token列表批量上报给Apple server进行销毁操作。 因此，对于这类产品的生产和开发而言，配件厂商需要首先要部署一台服务器，能够按照Apple定义的HTTPS Restful API与Apple Server进行通信。 服务器双向认证证书的申请 首先一点，配件厂商的服务器要能够与Apple Server之间在通信建立之前要先进行双向认证，双向认证通过后才能建立真正的业务通信。而要进行完整的双向认证，厂商就必须要在服务器之间进行通信之前向Apple申请一个经过Apple签名认证过的双向认证证书，并且部署在自己的服务器上。 厂商服务器双向认证证书的申请流程： - 首先，配件厂商需要先使用keytool工具生成一个证书签名请求文件CSR，在这个请求文件中应该包含这个配件厂商的公司名称字符串和MFI账号（应该是一个6位数字）。 - 登录MFI Portal账号，在Software Authentication Certificate Request下的Resources页面中，点击+New Request按钮，即可提交CSR证书给Apple进行审核。审核通过后，Apple Server就会返回一个签名证书，此时配件厂商应该把这个证书部署在自己与Apple Server通信的服务器上，用于后续两个服务器之间的双向认证通信。 - 注意，Apple的这个签名证书的有效时间是两年，配件厂商应该在这个证书过期之前在MFI Portal去更新证书。更新证书的流程与申请新前面证书的流程相同，拿到更新证书后应立即部署到自己的服务器上。 - Apple签名证书在厂商服务器上部署完成后，就可以尝试使用Apple预定义的HTTPS Restful API向apple server发出请求进行通信了。 配件厂商服务器与Apple Server之间的交互流程总结 对于以上支持Software Token Based MFI认证的三种品类的MFI外设而言，不同外设产品类型向Apple Server申请software token的Apple Server URL是不同的： - HomeKit： https://sauth-external.apple.com - AirPlay 2 Audio： https://swa.apple.com - Find My network： https://swa.apple.com 因此对于配件厂商而言，就需要按照自己所开发和生成的MFI配件类型，选择不同的URL与之通信来申请token。 配件厂商的服务器与Apple Server之间的通信，是标准的基于HTTPS的Restful API的访问形式，每次通信均由配件厂商的服务器发起请求，Apple Server返回应答信息。每一次请求对应一个操作，两者之间的通信所要实现操作主要包含以下几项： - 批量申请Token - 获取包含token的CSV文件的文件名列表 - 根据获取的CSV文件列表下载CSV文件 - 向Apple Server注册量产产品已经使用的token列表 - 批量申请销毁未使用的token列表 1. 批量申请Token 配件厂商向Apple申请该型号的配件开发与生产的项目经过appprove以后，Apple就会针对这个型号的配件提供一个Product Plan ID，以及默认为这个配件型号提供一定数量的software token（开发阶段是1000个，量产阶段是1百万个）。此时配件厂商就可以向Apple Server批量申请开发或者量产要使用的token。 批量申请Token的restful API是：api/v1.0/external/authEntityRequests。同时需要在请求消息中以json传递这个型号产品的PPID和要申请的token数量。 Apple Server对请求消息进行确认后，在其发回的应答消息中，返回一个Request ID（这个Request ID后续会被用于下载token）以及可以下载这批token列表的时间字符串。配件厂商必须要在这个时间之后向Apple Server进一步请求下载token列表。 2. 获取CSV文件名列表并下载 从Apple Server申请到的token列表会被apple server保存在一个CSV文件中，这个文件中的每一行都对应一条token。 - CSV文件中每一行所包含的token的格式：,,,, 每次CSV文件中最多可以保存2000个token，因此如果一次性请求的token比较多的话，Apple Server会针对这次请求生成多个CSV文件。 因此对于Token列表下载的这一步，实际上包含由两个API，分别是获取CSV文件列表的名称以及下载指定的CSV文件。 首先通过以下API获取这批token所保存的CSV文件的名称列表：api/v1.0/external/authEntities/{request_id}。此处需要使用批量申请Token流程中，Apple Server所返回的Request ID作为参数向Apple Server发起请求。 针对以上CSV文件名称列表的请求，Apple Server会在应答消息中以Json形式返回CSV文件的数量，以及CSV文件名称的列表。 接下来，配件厂商的Server就需要使用以下API向Apple Server下载CSV文件：api/v1.0/external/authEntities/{request_id}/{file_name}。其中的request_id就是批量申请token这一步Apple Server所返回的request id，而file_name就是前一步所获取到的CSV文件命令列表中所包含的文件名。因此，Apple Server针对这次token申请生成了多少了CSV文件，就需要调用多少次文件下载的API把这些文件一个个下载下来。 至此，Token申请以及从Apple Server上下载的流程就已经完成了。下一步就是配件厂商需要在量产产品的产线上把这些Token逐个写入到要出货的产品固件中。 3. 已使用Token向Apple Server的批量注册 接下来，在这个批次生产完成后，配件厂商还需要把这个批次生产过程中使用的token列表上报给Apple Server，表示这些token已经被用于量产的产品中。这样这些已出货的配件后续在终端用户首次配对使用的时候，才能够通过Apple Device的验证，成功绑定到用户的Apple账号之中。 配件厂商服务器向Apple Server上报注册已使用Token列表的API是：api/v1.0/external/bulk/usedAuthEntities。 在请求消息中应包含该配件的PPID以及要上报的token列表。Apple Server则会对这次请求返回一个Request ID。 值得注意的是，请求消息中所包含的token列表中的每一个Token元素都是Token ID : UUID这样的形式，那么这个UUID是怎么来的呢？ 事实上，所有的Token都是向Apple Server申请，由Apple Server返回给配件厂商Server。在量产过程中，实际上除了要写入这个token到配件产品固件中之外，还需要写入一个由厂商自行生成和管理的、独一无二的UUID到固件中。 也就是说，针对每一个token，厂商Server应该要同时生成一个独一无二的、符合RFC4122 Type 4规范的UUID，token和UUID建立一一对应关系，生产的过程中同时写入产品的固件之中。Token和UUID之间的这个一一对应的关系也需要在量产之后上报给Apple Server。 为什么要搞得这么复杂？通过Token的唯一性不就可以实现对外设产品的验证了吗？实际上这个设计与后续用户可能进行的恢复出厂操作有关。产线阶段写入的这个token会被用于用户首次使用和绑定的流程之中，按照Apple的安全性设计，每个token只能被在首次激活和绑定的时候使用一次。因此如果用户把这个配件恢复出厂设置的时候，apple device就会给配件下发一个新的token，替代掉之前已经用过的token（也就是在产线上写入的那个token），以用于下次重新配对到新的apple账号中使用。也就是说，Token在这个配件后续的使用过程中是有可能被修改的，这个时候就需要一个固定不变的ID用来标记这个配件产品，这个ID就是配件厂商需要在量产时与token同步写入固件的UUID。后续的使用过程，token可能会发生变化，但是UUID永远不会发生变化。 4. 未使用完的Token向Apple Server的批量销毁 除了以上常规的流程以外，针对那些申请了过多token，这些token在配件产品的这次量产中没有用完的情况下，Apple还提供了一个销毁token的流程，避免token被白白浪费。 当配件厂商在本次生产批次结束后，如果还有多余的token尚未用完，应该在其服务器上使用以下API申请销毁这些未使用的token：api/v1.0/external/bulk/unusedAuthEntities。在这个API的请求结构体中，应该包含这个配件产品的PPID，以及要销毁的token ID（因为这些token没有用于生产，也就不存在与之对应的UUID）。相应的，Apple Server在收到这个请求以后，会返回一个Request ID。 配件的激活流程 对于MFI配件的生产和使用而言，除了以上所描述的配件厂商服务器与Apple Server之间的交互，以及在量产过程中写入Token和SSID信息，并且上报给Apple Server之外，还存在一个配件首次使用的激活流程。 配件生产后进入市场销售，提前在生产阶段写入了token和厂商生成的UUID。那么在用户首次激活这个设备，并且尝试与自己的Apple device和账号绑定的流程之中（使用Apple Home APP或者Find My APP），Apple device会向配件请求读取其token，读到以后Apple Device还需要进一步Apple Server进行通信，把这个token发给Apple Server在云端进行校验和验证，确认其是合法的MFI外设设备。只有Apple Server验证通过的情况下，这个设备才能完成绑定的流程并正常使用。 参考文档 - Software Token Authentication Server Specification Release R2.1

基于Software Token的Apple MFI认证及其工作流程

Apple基于软件token的MFI认证介绍 众所周知，Apple对连接到其设备的第三方外设有着严格的质量标准、连接规范和安全要求。这确保了通过MFI认证的外设能为用户提供优质的体验和服务。因此，所有Apple产品外设在上市销售前都必须通过MFI认证。 Apple设备的MFI认证主要分为两类：基于硬件加密芯片的外设认证和基于Software Token的认证。其中： - 基于硬件加密芯片的认证主要适用于通过物理接口（如USB或Lightning接口）连接到苹果设备的外设，包括充电头在内。这种认证所需的硬件加密芯片价格昂贵，给许多外设制造商带来了巨大的成本压力。虽然对某些产品（如充电头）使用加密芯片的必要性值得商榷，但这是Apple制定的游戏规则。 - 基于Software Token的MFI认证则适用于通过WiFi或BLE等无线方式连接的外设。根据Apple的《Introduction to Software Authentication》文档规定，三类产品可以使用软件token认证：Apple Find My Network、Airplay Audio和HomeKit。因此，如果配件属于这三类产品，制造商可以避免购买昂贵的MFI硬件加密芯片，转而采用基于软件Token的认证方式。 所谓的Software Token，实际上是写入苹果外设硬件产品固件中的一串唯一标识字符串。这个Token由Apple生成并统一管理。配件厂商在量产外设产品时，需要向Apple批量申请Token，并在生产线上逐一写入产品固件中，确保每个产品都有其独特的Token。当用户购买并使用这些产品时，苹果设备可以通过验证Token来确认产品的合法性。 以Homekit为例说明MFI产品认证流程 以下以 HomeKit 产品为例，说明这些基于软件Token的MFI外设硬件产品的认证工作流程： - Product Plan：产品计划阶段。配件厂商需向 Apple 提交 HomeKit 外设的产品计划书并等待审核。审核通过后，Apple 会为该产品分配一个 PPID，用于后续申请 software token。 - PPID 申请完成后，Apple 会为每个产品型号提供 1000 个软件 token，用于产品开发和测试。 - Development：产品开发阶段。配件开发商需学习《HomeKit Accessory Protocol Specification》和《Works with Apple Home Identity Guidelines for HomeKit》文档，并使用 Apple 维护的 HomeKit Accessory Development Kit (ADK) 进行产品开发。这些文档和开发包可从 Apple 的 MFI portal 账号下载。开发过程中，可使用 HomeKit Certification Assistant (HCA)、HomeKit Accessory Tester (HAT) 和 HomeKit Certification Test Cases 等测试工具进行调试。如果产品需要配套 APP，还可使用 HomeKit App Test Cases 进行 APP 测试。 - 在此阶段需使用 PPID 申请时获得的 1000 个软件 token 进行开发测试。 - Accessory Production-Ready Certification：产品开发和自测完成后，提交至 Apple 进行 MFI 认证。需按照认证流程提交相关文档（HomeKit Product Compliance Questionnaire）和 5 个测试样品。如认证过程中发现问题，需反复整改直至通过认证测试。 - Packaging Certification：产品包装认证。按《Works with Apple Home Identity Guidelines for HomeKit》要求设计包装，并提交设计文件供 Apple 审核。 - (If applicable) App Certification：如产品需配套 APP，则需完成 APP 认证测试。 - Mass Production：量产阶段。对于基于 Software Token 的 HomeKit 产品，需在生产线上通过产测程序将从 Apple Server 申请的 token 写入产品固件。每个产品的 token 都是唯一的，并由 Apple Server 统一管理。该外设产品后续在使用过程中与苹果设备连接时，就可以通过验证 token来确认产品MFI认证的合法性。 到了这一步量产中所生产的产品就可以打上这个标了： !1733389026260.png 基于Software Token的MFI认证工作流程 1. 请求Token 按照Apple所设计的Software Token Based MFI产品的认证与工作流程中，这些产品中生成所需要写入的Software Token需要提前向Apple批量申请。这个申请过程需要配件生产商部署一个服务器，与Apple的MFI认证Token服务器进行通信，两个服务器之间通过基于HTTPS的Restful API进行通信，进行Software Token的批量申请、下载、注册以及销毁等操作。 每次进行的批量Token操作，都由配件厂商所部署的服务器发起请求（Apple对于配件厂商所部署的服务器也有一定的安全性和双向认证的要求，相关的认证证书需要按照流程向Apple申请并部署到自己的服务器上，才能与Apple Server进行有效的通信），Apple Server返回响应。申请到的Token保存在CSV文件中，包含在Apple Server的响应消息中，配件厂商应该妥善保管这些token并在后续的产品量产过程中写入产品固件中。 注意：每个MFI外设产品在立项通过Apple审核后拿到PPID，该产品在开发阶段可以申请1000个token用于产品的开发和测试。而产品量产后，单个型号的产品所能申请的Token数量默认最多为100万个。如果超过这个数量可以通过MFI Portal向Apple单独提出申请超额的token。 2. 量产阶段烧写Token到产品固件中 量产之前首先完成了该产品的MFI认证，并通过前一步骤向Apple Server申请到了本次量产所需要使用的Token列表。 量产过程中，配件生产商应该具有一定的产测手段，在生产中针对每个产品写入一个Token。 其实除了以上在量产阶段写入Token到固件中以外，Apple针对那些已经量产出货、但尚未写入token的产品，提供了一种基于APP的MFI Software Token写入的流程。大体上就是这个配件厂商需要针对这类产品开发一个iOS APP功能，在这个APP中使用iOS的performAccessorySetupUsingRequest API去发起这个所谓的In-Field Provisioning的过程，实现通过APP写入并注册Token到Apple Server上的完整流程。 - 这个基于APP的MFI Software Token写入流程只针对Homekit和Airplay Audio品类的产品，不支持Find My品类的产品。所以如果是Apple Find my品类的产品，一定是要在量产阶段提前写入token才行。 3. Token的注册 以上量产过程写入Token到量产的外设产品固件中以后，还需要按照Apple所定义的注册流程（Registration）把这批量产产品所使用的Token列表上报给Apple Server。这个上报过程同样是使用配件厂商所架设的服务器与Apple Server之间进行的HTTPS Restful API来实现。 只有已经在Apple Server中注册过的Token ID才能在后续用户使用的过程中，与用户的Apple Device进行绑定和激活。 4. Token的激活 Token的激活发生在用户购买这个外设产品，第一次与用户的Apple device进行配对和设置时发生。在用户通过自己的Apple设备绑定这个外设产品时，用户的Apple Device就会与Apple server配合对这个设备中所包含的Token的合法性进行验证，验证后即可加入到自己的外设产品列表之中正常使用。 需要注意的是，每个token在激活和绑定这个设备时只能够被使用一次。如果后续用户把外设产品恢复出厂设置时，用户的apple device就会给这个外设下发一个新的Token，外设需要把这个新的Token保存起来用于下一次所进行的新的外设配对和设置操作。 参考文档 - Introduction to Software Authentication Release R3 - HomeKit Certification Process - Software Token Authentication Server Specification Release R2.1

基于Homekit的Video Camera生态调研总结

因工作需要，对Apple Homekit生态下的Video Camera进行调研和总结，判断是否可以作为下一个产品预研点的选项之一。因此以下资料仅包含对网络公开资料的学习和总结，尚未拿到Apple Homekit MFI认证相关的文档和资料，也没有进行实际设备在苹果Homekit生态中实际使用体验和测试。 Homekit生态基本总结 Homekit是Apple在2014年6月份的全球开发者大会WWDC中发布的智能家居生态。Homekit本质上是苹果针对智能家居领域所定义的一套标准和规范，基于对标准规范的支持，该生态下的智能家居设备可以方便的通过苹果设备和语音助手Siri进行交互通信和自动化控制。 在Apple Homekit智能家居生态之中，苹果提供了这个生态与用户之间进行访问和交互的入口，定义了一套所有的设备与接口之间的通信协议和规范，由各个硬件厂商按照这个协议规范来实现不同类型的智能家居硬件，当然开始销售之前需要通过Apple Homekit类型的MFI认证（Works with Apple Homekit）。硬件厂商所开发的只能家居硬件一旦通过以上认证，就可以与同样遵守Apple Homekit规范的其他厂家所生产的智能家居设备在同一个生态下进行通信。 - 苹果的典型访问入口设备包括：iPhone，iPad，MAC，Homepod，Apple TV，Siri，甚至包括Apple Watch。 - 苹果自己并不生产智能家居硬件，而是提供了一套可与苹果设备进行交互的智能家居协议规范，由各个硬件厂家基于这个规范开发智能家居硬件产品，通过Homekit的MFI认证后即可加入苹果的Homekit智能家居生态。这样就避免了苹果自己生产制造硬件与各个硬件厂商之间的竞争关系，有利于生态的推广。 在苹果设备上，Homekit的访问入口是Home家庭APP。在Home APP中包含了对多种典型的智能家居设备类型的支持。比较典型的就是各种传感器（温湿度、气体、烟雾探测）、门锁、摄像头、灯、开关插座、家电等。 !Untitled.png Homekit本质上是基于局域网的 按照我自己之前的理解，苹果的Homekit生态，应该就是Apple需要针对主流的智能家居产品的应用，搭建一个云服务，这样所有以wifi连接方式的智能家居产品就可以直接连接Apple的智能家居云服务。但是经过更深入的学习（尤其是参考链接4），才发现并非如此，Apple的Homekit在网络通信层面上是基于局域网的，所有的消息都是在局域网内部流转的，Apple针对Homekit并没有提供完整的远端云服务层面上的智能家居支持。这一点跟小米的米家还是有着非常大的区别，米家的所有设备都是直接连接小米的米家云服务平台的，所以可以通过小米的云服务来实现直接控制，因此实际上米家的设计在使用上更方便一些。 当然，Homekit生态工作在局域网之内的设计也有着诸多好处： - 所有的用户数据都在局域网内，个人数据的隐私保护和安全性最好。 - 在局域网内使用，通信数据的收发速度很快，智能家居产品和服务在局域网内使用的情况下，响应速度很快。 - 只要局域网正常，即使外网断了（当然这种情况极少），在局域网内部使用Homekit的所有功能仍然是正常的。 - 其实对于大多数智能家居产品的使用场景而言，基本上都是在家内的局域网环境中使用的，所以其实在局域网内使用就可以满足绝大多数的要求。当然Apple当然也针对在外网对家庭内部的Homekit生态设备提供了解决方案。 那么针对需要在远端对Homekit生态下的智能家居设备进行远程访问和控制的话，应该怎么做呢？答案就是一定要在局域网内有一个Apple Homekit的控制中枢。这个控制中枢可以是苹果的HomePod智能音箱，Apple TV或者iPad（尽管目前仍然支持使用iPad作为控制中枢，但是Apple更建议使用Homepod或者AppleTV作为控制中枢，从网络上也能够查到使用iPad作为中枢存在一些不稳定性方面的问题）。在链接将 HomePod、HomePod mini、Apple TV 或 iPad 设置为家居中枢 - 官方 Apple 支持 (中国)中提供了设置以上设备为Homekit控制中枢的指南。 也就是说，HomeKit本身是基于局域网进行通信的，但是如果有远端访问家庭内智能家居设备的需求的话，就一定要先在自己的Home APP中设置一个Homekit控制中枢，并且保证这个控制中枢与自己所有的HomeKit智能家居产品处于同一个局域网内，并且保持通电状态，这样处于外网的iPhone和MAC等设备就可以通过苹果的iCloud服务把控制命令发给家里的Homekit控制中枢，然后再由控制中枢中转发给自己指定的智能家居设备。 Homekit Secure Video System功能支持的基本情况 Homekit对于IP Camera支持的服务全称是 Apple’s HomeKit Secure Video system (HSV)，从名称上就可以看出来主打的就是安全。目前HomeKit摄像头产品所提供的支持来看，主要包含了indoor camera，outdoor camera以及doorbell camera这几个品类。Eufy，Logitech、Aqara、Eve等厂家都已经推出了可以支持Homekit生态的摄像头产品。 当然，为了能够流畅的使用Homekit生态下的Secure Video System服务，至少需要有一个Homepod/Apple TV/iPad作为控制中枢，以及需要iCloud订阅来上传和保存camera的事件录像片段。 目前Apple iCloud对于HSV Camera上传录像片段的订阅费用如下： - 50 GB plan (3 or £3 a month): up to five cameras. - 2 TB plan (的订阅费用，应该来说这个价格还算是比较亲民的（当然Homekit对于这些IP Camera支持的专业性上还是要差很远），尤其是考虑上传的事件录像视频片段并不会占用iCloud的存储额度。 对于一个典型的智能家居摄像头而言，其基本功能无外乎： - 事件录像功能：通过PIR或者图像检测等方式侦测触发事件，触发后拍一段录像存卡或者上传云端保存。 - 实时流功能：用户可以自己想要查看摄像头当前的实时流时，随时拿起手机打开APP查看实时流。 对于事件录像功能，摄像头本身仍然按照自己的工作逻辑检测事件并录像即可，但是在Homekit生态的实现下，额外就需要考虑如何上传事件录像文件到iCloud上。按照我的理解，因为Homekit本身是基于局域网的，所以事件录像文件上传iCloud，就只能依赖于家庭中枢设备才行：即由家庭中枢设备负责把收到的事件录像视频文件上传到iCloud，一旦上传iCloud以后，自然就可以在Home APP上回放观看这些事件录像文件了。 对于实时流功能大致应该也是如此。通过Home APP的实时拉流指令首先发到家庭中枢设备上，然后家庭中枢设备从Homekit摄像头上拉流再转发到Home APP上解码显示出来。 > 💡 此外，Apple并不限制摄像头硬件生产商在Homekit生态的基础上，额外增加自己的特殊功能、APP和Cloud业务的支持。因此，对于摄像头生产商而言，可以在产品设计中同时内置对于Homekit生态的支持，以及对于自己的APP+云业务的支持；而用户而言，也同时可以在同一个摄像头硬件上，打开Apple Home APP来使用Homekit的功能，而对于一些Homekit上无法支持的功能，则可以使用硬件厂商所提供的APP来实现。 Homekit Secure Video的优缺点 Strength： - Apple在用户隐私数据的保护上口碑一直比较好，这一点对于摄像头而言尤其如此，这也是极其注重个人隐私的欧美用户青睐Apple生态的原因之一。按照Apple的宣传，所有的视频数据以及Video Live Streaming数据，都是端到端加密的，只有用户自己能看到，即使是摄像头的硬件厂商以及Apple自己都没法访问这些隐私数据。 - 可以支持基本的人脸识别、人形、车辆、包裹、宠物检测、Multiple Motion Zone等算法，可以基于这些检测结果设置不同的触发事件类型。 Weakness： - 基于Homekit的相关功能只能在苹果生态下使用，用户无法通过Android系统使用Home App。 - HSV只支持基于触发事件的视频录像数据上传到iCloud，不支持7x24连续录像。 - 最高只能支持1080P分辨率，这一点与较为专业的IPC相比，还是一个比较大的短板所在，现在主流厂家推广的新品基本上都是2K和2.5K了。 - 缺乏一些基本的功能支持，Siren，云台控制等。 参考资料 - Apple HomeKit Secure Video: Pros and Cons | WIRED - All Netatmo Smart Cameras now support HomeKit Secure Video - HomeKit connection from Philips Hue requires a home hub - Hueblog.com - 从苹果生态环境的优越性来看看HomeKit有多厉害 - 知乎 (zhihu.com)

Apple Find My的Unwanted Tracking Alert功能详细解析

最近因为公司一个新项目的开发需求，开始学习Apple MFI Find My Network的协议文档。 因为是基于BLE的，而且功能也比较简单（主要就是防丢，帮助用户快速找到自己设备的位置），整个协议的工作逻辑还是简单的。但刚开始学习的时候，还是对其中的Unwanted Tracking Alert的功能特性和使用逻辑不是很清楚。 Apple Find My Accessory的四种工作状态 要搞明白Unwanted Tracking Alert，首先要弄清楚Apple Find My Accessory的四种工作状态： !Untitled.png 本质上，Apple Find My Accessory实际上就是一个基于BLE Beacon以及连接模式的位置跟踪器。那么对于任何的蓝牙设备而言，大致无非就是配对前的广播状态、配对后的广播状态（未连接），以及连接通信状态。所以以上的Unpaired和Connected状态是比较好理解的，但是Nearby和Separated是什么意思？区别是什么？ 实际上Nearby和Separated这两种状态的区别就跟Unwanted Tracking Alert功能息息相关了。 - Unpaired：就是Find My Accessory的未配对模式，所有的这类设备出厂后刚开机的时候就处于这种状态下，持续的发出广播包等待与用户的Apple设备进行首次配对。 - 除了一开始的初始状态以外，如果这个accessory解绑unpairing以后，每次开机也是处于这种状态之下。 - Connected：就是Accessory与用户Apple设备之间处于正常的连接状态，用户可以在apple设备的find my app上看到设备的位置，控制设置发出声音以更方便的进行定位。 - Nearby：当accessory和用户的apple设备之间的BLE连接断开后，总是首先会进入Nearby状态。这个Nearby状态本质上还是一种BLE的广播状态，这个状态的目的就是等待与用户的Apple设备重新建立连接。这种状态下不支持Unwanted Tracking Alert功能。 - Separated：Nearby状态下会维持一个倒计时器，当accessory处于Nearby状态的时间超过TNearBy（默认为15min，但是可以在apple device的find my app连接状态下修改）后，这个Accessory就会自动进入Separated状态。Separated状态与Nearby状态在实现上的最大区别就是，Separated状态有Unwanted Tracking Alert功能，而Nearby状态没有。 我自己对于以上状态的理解： - 实际上对于Find My Accessory而言，经过pairing操作以后，正常使用中绝大多数状态应该就是Connected和Nearby。Connected当然就表示手机跟Accessory之间的距离很近，双方一直保持正常连接；而Nearby则是手机和Accessory之间短暂离开（离开时间不超过15min）的状态。 - Separated状态则是表示手机跟Accessory之间已经超过15min不在一起了，存在丢失的风险或者已经丢失了。所以处于丢失状态下的Find My Accessory实际上就是处于这种状态 - 可以理解Nearby状态是用户Apple device与Accessory的临时断开状态，如果断开的状态时间太长进入了Separated状态，就认为是进入丢失状态了。 - 后续完整的Unwanted Tracking Alert功能全部都是与Separated状态来进行设计的。 那么Unwanted Tracking Alert功能究竟是什么？ 按照参考文档1第2.6.1 Unwanted Tracking Detection节的描述： - Unwanted tracking detection (UT) notifies the user of the presence of an unrecognized accessory that may be traveling with them over time and allows them to take various actions, including playing a sound on the accessory if it’s in Bluetooth LE range. 也就是说，Find My Accessory的基本功能实际上就是一个BLE防丢器，配合Apple的Find My Server以及强大的苹果产品生态，可以为用户方便的定位这个Find My Accessory所在的准确位置。 但是，这个功能也很容易被人恶意用于跟踪，最典型的就是：跟踪者把一个与自己Apple账号绑定的Find My Accessory放入被跟踪者的车辆、背包等里面，然后无论这个被跟踪者到哪里，跟踪者都可以很容易的用自己的find my app查到到被跟踪者的精确位置。 因此Apple Find My Accessory中的这个Unwanted tracking detection或者alert的功能就是通过： - Accessory在长时间进入Separated状态后，定期通过Motion Detector检测Motion，并主动发出告警声音。 - 以及在潜在被跟踪者的手机上监测到异常后弹出Alert的方式进行告警。 以上两种方式来提醒用户，以缓解和应对位置隐私信息泄露带来的危险。 Find My Accessory端的Unwanted Tracking Alert功能实现 正是因为find my accessory很容易被人用于恶意的跟踪他人的位置，所以在Apple的find my accessory specfication里面明确要求，小尺寸的Find My Accessory一定要有Sound Maker（例如喇叭，蜂鸣器）和一个Motion Detector（例如g-sensor）用于辅助快速找到隐藏的跟踪设备。 如果不满足以下尺寸要求，就一定要有Sound Maker和Motion Detector来实现Unwanted Tracking Alert功能： !Untitled.png 而对于这个accessory而言，Unwanted Tracking Alert功能的大致实现流程如下： - Accessory进入Separated状态后，等待TSEPARATED_UT_TIMEOUT时间（默认为3天），启用Motion Detector功能。 - 此后以TSEPARATED_UT_SAMPLING_RATE1为周期（默认为10s）使用Mition Detctor检测当前是否处于Motion。 - 如果检测到Motion，就通过Sound Maker播放一次声音，同时后续修改Motion Detector的检测周期为TSEPARATED_UT_SAMPLING_RATE2（默认为0.5s），同样每次检测到Motion就播放一次声音，以提醒用户注意。 - 如果已经播放过10次声音，或者以TSEPARATED_UT_SAMPLING_RATE2为周期连续检测到20秒Motion事件，则禁用Motion Dector一段时间 TSEPARATED_UT_BACKOFF（默认为6小时）。然后再周而复始。 通过以上流程，当Accessory处于Separated的状态下超过一定的时间后，就会定期的打开Motion Detector进行Motion检测，检测到Motion后再通过Sound Maker来提醒用户可能被跟踪。 iOS手机端的Unwanted Tracking Alert功能特性 除了Accessory自身在Separated状态下，周期性的通过Motion Detection+Sound的方式提醒可能被跟踪以外，用户的Apple设备端（例如iOS手机）也会在判断周围有处于Separated状态的Find My Accessory持续跟踪的情况下，在手机系统中推送Alert消息如下。当系统收到Alert消息以后，点击进入Find My APP就会找到自己附近的Find My Accessory设备。此时还可以通过Play Sound来控制这个跟踪器发出声音，从而更快速的找到这个跟踪器的位置。 !Untitled.png !Untitled.png 对于iOS手机系统如何判断自己是否被一个跟踪器持续跟踪，我的理解是： - 手机的BLE打开的情况下持续的扫描周期的BLE设备，当然也就包括使用BLE的Find My Accessory设备。 - 如果手机系统检测到自己周围有一个处于Separated状态下的Find My Accessory设备，默认情况下会按照Find My Server运行的流程，从Find My Accessory设备BLE广播包中包含的密钥，加密自己所在的位置上报给Apple Find My Server。 - 但是如果手机系统检测到这个处于Separated状态下的Accessory在自己周围的时间过长，就会在系统上弹出Alert警告用户可能被跟踪。 这里值得注意的一点是，用户可以通过Find My APP控制周围处于Separated状态下的Accessory发出声音，来更快的找到这个Accessory所在的位置。既然要控制，那么用户的手机就一定要能够与这个Accessory建立BLE连接才行，Beacon模式肯定是没法实现控制的。因此在整个Find My的工作流程中，Non Owner的apple设备也就是手机，是可以与Find My Accessory建立连接并进行控制通信的。这个情况下这个控制指令，实际上使用的是Accessory中所实现的BLE Find My Network service中的Non Owner Control Point Characteristic： !Untitled.png 其他问题 1. Android设备对于Apple Find My Accessory的Unwanted Tracking Alert特性的支持情况？ - 实际上Google在这个方面也已经在仿效Apple打造自己的Find My Accessory生态，根据Nordic代理渠道得到的信息，目前国内已经有厂家使用Nordic的nRF52系列配合Google的find my协议需求完成了这部分功能的实现。 - 而根据参考文档2中Apple官方网站提供的描述，Apple和Google已经针对Find My的Unwanted Tracking Alert特性达成了协议一致性的产业标准（draft-detecting-unwanted-location-trackers-01 - Detecting Unwanted Location Trackers (ietf.org)），以后无论用户是使用Android还是iOS的手机，都可以在触发Find My Unwanted Tracking Alert特性的情况下，在手机上收到可能被跟踪的警告信息。 !Untitled.png 1. 当通过手机系统的Alert Message或者Accessory的周期性Motion Detection+Sound的机制发现跟踪设备后，如何处理？ - 从参考文档3给出的信息，除了把这个跟踪器扔掉以外，另外一个办法就是把这个跟踪器强制关机或者拔掉电池。 参考文档 - Find My Network Accessory Specification Release R2 - Apple and Google deliver support for unwanted tracking alerts in iOS and Android - Apple (HK) - How to find out if an AirTag is tracking you | ZDNET - 浅析 Find My 原理 - Yibin! - 博客园 (cnblogs.com)