上一篇把 Aliro 1.0 的协议骨架拆过一遍。这篇换个视角假设你要在一个门锁主控上把 Aliro 跑起来从零到解锁每一步该实现什么、踩什么坑。Aliro 最折磨开发者的不是协议本身。它的 APDU 命令框架和 CCC 数字钥匙同源做过车钥匙的人不陌生。真正难的是三通道协作BLE 做发现、UWB 做测距、NFC 做兜底三条无线通道各有各的状态机还要在门口那一刻严丝合缝地接起来。BLE 没协商好UWB 测距会话起不来UWB 没拿到可信距离不能触发解锁BLE 和 UWB 都挂了NFC 才顶上。任何一个环节时序错了要么解锁不了要么被中继攻击打穿。下面按三通道技术角色 → 协议交互流程实现 → 安全实现要点 → 开发踩坑与兼容性四块展开。协议事实来自 Aliro 1.0 规范CSA 文档 26-42802-001实现建议结合 BLE/NFC/UWB 通用开发经验文中会明确区分规范要求和实现建议。一、三通道技术角色谁干什么先理清三通道在 Aliro 里的分工。规范第 9 章定义了三种传输流程纯 NFC、BLEUWB、纯 BLE。三种流程对应三种使用姿态但底层三通道的角色定位是固定的。1.1 BLE发现与控制通道BLE 在 Aliro 里的定位是发现 控制不是测距。规范第 11 章把 BLE 的角色定死Reader 是 GAP Peripheral GATT ServerUser Device 是 GAP Central GATT Client。注意这个角色分配门锁是广播方手机是扫描方。这和直觉有点反通常我们以为锁是被动响应的但在 BLE 里锁要主动广播让手机发现自己。规范要求第 11 章BLE Core 4.2 是强制最低版本5.2 推荐。配对pairing是可选的不是必须。广播用 LE 1M PHY 的 ADV_INDAliro 服务 UUID 是0xFFF2。广播 payload 第 7 字节是能力位图bit7 表示是否支持 BLEUWBbit6 表示是否支持纯 BLEbits[4:3] 是通知码0/1/2/3 无错误/未知错误/低电量/传感器触发bits[2:0] 是广播版本号当前为 0。广播里带truncated_reader_group_identifierreader_group_identifier 的前 8 字节和truncated_reader_group_sub_identifier前 2 字节让手机能初步识别这是哪组锁。手机发现 Reader 后从 Reader 的 GATT server 读 SPSML2CAP 通道的 Service Protocol Security Multiplexer建立 L2CAP CoConnection-Oriented通道访问协议的 APDU 就跑在这条通道上。实现建议BLE 这层你要实现的清单是广播带 Aliro UUID 和能力位图、扫描手机侧、GATT server暴露 SPSM 特征、L2CAP Co 通道建链与数据收发。这些用各平台的 BLE API 都能做但要注意 Aliro 不强制 BLE 配对意味着 BLE 链路本身不提供加密加密由访问协议的 expedited 阶段在应用层做。别误以为 BLE 连上了就安全了。为什么测距不靠 BLE两个原因。一是精度BLE 的 RSSI信号强度估距精度是米级受环境影响大门锁场景要求分米级甚至更准。二是安全BLE 信号能被中继。攻击者放两个设备一个在车边收手机信号一个在远处把信号转给车车以为钥匙在边上就解锁了。这就是经典的中继攻击BLE 物理上防不住。所以测距必须交给 UWB。1.2 UWB测距与防中继UWB 在 Aliro 里的定位是精确测距 防中继。规范第 12 章把 UWB 的 MAC/PHY/安全直接引用 CCC Digital Key Spec v4.0.0 的 section 20/21/22Aliro 自己只定义了少量扩展。可以理解为 Aliro 的 UWB 部分基本是 CCC 数字钥匙那套测距技术的门禁版移植。规范要求第 12 章UWB 角色和 BLE 是反的User Device 是 Initiator发起测距Reader 是 Responder响应测距。一个 ranging block 里可以用 1 或 2 个 ranging round 做测距。两个 round 能让 Reader 判断手机是在门前还是门后防站在门后蹭开攻击。Reader 可以只支持 1 个 round但 User Device 必须支持 2 个 round。测距会话通过 M1-M4 四条消息协商参数详见第 2.4 节。UWB MAC 的 Vendor OUI 固定为0x4A191BCSA 在 IEEE 注册的公司标识。安全时序 STSScrambled Timestamp Sequence的密钥 URSK 有 12 小时 TTLSTS_INDEX 最大到 2^31-1。STS_INDEX 到顶、丢失、TTL 过期、BLE 连接断开都要丢弃 URSK。UWB 测距用飞行时间ToF精度到 10 厘米级。更关键的是 STS它给每个测距消息加一个加扰时间戳攻击者转发信号时时间对不上物理上无法中继。这是 UWB 防中继的核心第 3.2 节展开。实现建议UWB 这层你大概率不会从零写 PHY/MAC而是用 FiRa 兼容的 UWB 芯片NXP、Qorvo 等加 SDK。你要做的是把 Aliro 协商出的测距参数STS index、hopping 序列、SYNC code 等喂给 UWB 芯片启动测距会话拿回可信距离。选芯片时确认它支持 STS 和 Aliro/CCC 要求的测距模式别选只支持简单 ToF 不带 STS 的低端芯片。1.3 NFC最后防线NFC 在 Aliro 里的定位是兜底。手机没电关机了UWB 和 BLE 都跑不起来但 NFC 卡片模拟可以靠 Reader 的射频场供电照样能刷。这是 Apple Home Key 一直在宣传的 power reserve 特性Aliro 把它标准化了。规范要求第 10 章Reader 工作在 Poll ModeNFC-A、T4AT、ISO-DEPUser Device 工作在 Listen 模式。用 SELECT 命令建立会话CLA0x00、INS0xA4、P10x04、P20x00。两个 AIDA000000909ACCE5501是 expedited 通道A000000909ACCE5502是 step-up 通道。SELECT 响应是 FCI 模板含 0x6F、0x84AID、0xA5专有、0x80Type固定 0x0000 表示 CSA 应用、0x5C协议版本、0x7F66扩展长度、0xB3厂商扩展、0xB7User Device Descriptor0x04 厂商 ID 3 字节、0x80 产品 ID、0x81 固件版本。响应不超过 256 字节。有个 CONTROL FLOW 命令INS0x3C数据里 0x41 是 S1、0x42 是 S2、0x63 是 Reader Descriptor。S10x00 表示失败S20x00 表示无信息、0x27 表示协议版本不支持。Reader 在 EXCHANGE 完成前不应显示成功在 CONTROL FLOW 前不应显示失败。访问决策一出来就可以触发机械动作。实现建议NFC 这层在手机侧走 HCEHost Card Emulation或 SE 内的 applet在锁侧用 NFC 读卡芯片。关键是要把两个 AID 都注册好让锁能根据手机回的 FCI 判断走 expedited 还是 step-up。NFC 带宽低ISO-DEP 典型 106kbps 起步命令要尽量精简别在 NFC 通道上做大证书传输。大证书走 LOAD CERT 但要考虑 NFC 的 256 字节响应上限和分块。1.4 角色反转的坑三通道的角色分配有个容易搞混的点BLEReader Peripheral广播User Device Central扫描UWBUser Device Initiator发起Reader Responder响应两套角色是反的。这不是规范写错是有意为之BLE 阶段锁要被手机发现所以它广播UWB 阶段手机要主动测距所以它发起。开发时两套角色映射别搞混尤其是同一个设备同时维护 BLE 和 UWB 两套状态时别把我是 Central的假设带进 UWB 逻辑里。二、协议交互流程实现把三通道接起来看一次完整的无感解锁时序。这是开发者最需要吃透的部分。2.1 整体时序发现 → 认证 → 测距 → 解锁BLEUWB 流程的主路径规范第 11 章发现锁广播 BLE带 Aliro UUID 0xFFF2 和能力位图手机扫描发现读 SPSM建 L2CAP Co 通道。expedited 认证在 L2CAP 通道上跑 AUTH0必要时 LOAD CERT、AUTH1建立安全通道完成互认证。下发 URSKReader 用 EXCHANGE 命令tag0x98把 URSK 推给 UWB 传感器通知 Reader Status Access Protocol Completed然后删除会话密钥。UWB 测距手机作为 Initiator 启动测距会话M1-M4 协商参数拿可信距离。解锁距离在阈值内Reader 触发机械动作。纯 BLE 流程不一样没有 UWBBLE 既做发现又做传输但只走 expedited-standard规范明确 expedited-fast 在纯 BLE 下 SHALL NOT 使用且需要用户在设备上显式选择凭证explicit user selection。因为没 UWB 测距没法无感必须用户主动确认否则中继防不住。纯 NFC 流程贴卡SELECTAID 选 01 或 02走 APDU 序列断电兜底。2.2 expedited 阶段AUTH0 与 AUTH1 的实现expedited 阶段是协议核心。规范第 8 章把一次交易分成三步交易初始化、expedited 阶段必选、step-up 阶段可选。expedited 又分 standard 和 fast 两种。AUTH0 命令规范 8.3.3.2头CLA0x80、INS0x80、P10x00、P20x00。数据字段Table 8-40x41command_parameters1 字节bit00standard1fast0x42authentication_policy0x5Cexpedited_phase_protocol_version0x87reader_ePubK65 字节0x04||x||yECC P-256 临时公钥0x4Ctransaction_identifier16 字节0x4Dreader_identifier32 字节 reader_group_identifier 16 reader_group_sub_identifier 160xB1厂商扩展响应Table 8-50x86credential_ePubK65 字节User Device 临时公钥0x9Dcryptogram64 字节仅 fast 模式有0xB2厂商扩展规范要求Reader 每次都生成新的临时密钥对ECC P-256和新的 transaction_identifier选协议版本 0x0100。User Device 也生成临时凭证密钥对按 reader_group_identifier 查 Kpersistent。fast 模式下用 cryptogramSKAES-GCM 加密 payloadtagReader 用试错法拿手上的多个 Kpersistent 逐个解。User Device 要做抗时序攻击查不到凭证时返回一个用随机密钥构造的 mock Access Credential让攻击者无法通过时序判断手机里有没有这个凭证。AUTH1 命令规范 8.3.3.4头CLA0x80、INS0x81、P10x00、P20x00。数据字段Table 8-100x41command_parametersbit00要 key_slot1要完整公钥0x9EReader 签名64 字节ECDSA over Table 8-12 字段0x90reader_Cert可选压缩后的 Reader 证书响应Table 8-11加密后的 payload含0x4Ekey_slot 或0x5A完整公钥、0x9EUser Device 签名、0x4Bmailbox_data_subset、0x5Esignaling_bitmap。规范要求AUTH1 只能在 AUTH0 或 LOAD CERT 成功后发。Reader 用长期私钥对 Table 8-12 的字段reader_identifier、credential_ePubK.x、reader_ePubK.x、transaction_identifier、usage0x415D9569签名。usage 字段是反重放用的固定标识Reader 侧 0x415D9569User Device 侧 0x4E887B4C不一样是为了防反射攻击。User Device 验签后用 ECKA-DH 算 Kdh再走密钥派生。响应用 ExpeditedSKDevice 加密AES-GCM。实现建议实现 AUTH0/AUTH1 时重点把这几个点做对临时密钥对每次新生成别复用、transaction_identifier 用真随机数16 字节、抗时序攻击的 mock 凭证路径查不到也要走完整流程返回相同错误码、AES-GCM 的 IV 和 counter 管理见第 3.1 节。下面是 AUTH0 处理的伪代码骨架// 规范要求每次交易生成新临时密钥对和 transaction_identifier int reader_send_auth0(uint8_t fast_mode) { ec_keypair_t reader_eph; // ECC P-256 临时密钥对 uint8_t txn_id[16]; // transaction_identifier uint8_t reader_id[32]; // reader_group_id(16) sub_id(16) ec_generate_keypair(reader_eph); // 每次新生成 rng_fill(txn_id, 16); // 真随机 lookup_reader_identifier(reader_id); apdu_t apdu { .cla0x80, .ins0x80, .p10x00, .p20x00 }; apdu_add_tag(apdu, 0x41, 1, fast_mode); // command_parameters apdu_add_tag(apdu, 0x87, 65, reader_eph.pub); // reader_ePubK apdu_add_tag(apdu, 0x4C, 16, txn_id); // transaction_identifier apdu_add_tag(apdu, 0x4D, 32, reader_id); // reader_identifier // ... authentication_policy, protocol_version 等 return send_apdu(apdu); } // 规范要求抗时序攻击查不到凭证也要走完整流程 int user_device_process_auth0(apdu_t *req) { uint8_t group_id[16]; extract_tag(req, 0x4D, group_id, 16); // reader_group_identifier cred_t *cred lookup_credential(group_id); if (cred NULL) { // 实现建议构造 mock 凭证用随机密钥走完整流程 cred build_mock_credential_with_random_keys(); // 返回与有凭证但验签失败相同的错误码时序也要一致 } // ... 生成临时凭证密钥对fast 模式算 cryptogramstandard 模式准备 AUTH1 return build_auth0_response(cred); }2.3 EXCHANGE 下发 URSK 切 UWB认证通过后Reader 用 EXCHANGE 命令把 URSK 推给 UWB 传感器。这是 BLE 和 UWB 的衔接点。规范要求8.3.3.5EXCHANGE 在 expedited 阶段用 ExpeditedSKDevice/ExpeditedSKReader 加密在 step-up 阶段用 StepUpSKDevice/StepUpSKReader。EXCHANGE 能读写 mailbox、发 notify。BLEUWB 流程里Reader 用 EXCHANGE 带 tag0x98触发 URSK 下发到 UWB 传感器然后发 Reader Status Access Protocol Completed删会话密钥。NFC 流程里 EXCHANGE 用 tag0x97标记交易结束和最终状态BLE 流程里 tag0x97只在失败时出现。带0x97后不能再发 EXCHANGE。实现建议EXCHANGE 这步的工程要点是密钥切换和会话清理。URSK 下发完BLE 侧的 expedited 会话密钥要按规范删掉别留着复用防泄露UWB 侧用 URSK 启动 STS。BLE 连接断开、STS_INDEX 到顶、TTL 过期都要触发 URSK 丢弃。状态机里这条清理路径容易漏是中继攻击的潜在入口。2.4 UWB 测距会话M1-M4 协商UWB 测距会话通过四条消息协商参数规范 12.1.4。这个流程是 UWB 侧的核心开发者要把这些参数正确喂给 UWB 芯片。规范要求M1-M4M1Responder→InitiatorUWB Configuration Identifier、Pulse Shape Combination、Channel Bitmask可用 RF 信道列表、UWB Session Identifier。M2Initiator→Responder选定的 UWB Configuration Identifier、Pulse Shape Combination、Channel Bitmask、SYNC Code Index Bitmask可用前导序列、RAN Multiplier设最小 ranging block 时长TBlock_RAN N_RAN × 96ms、Slot Bitmask、Hopping Configuration Bitmask。M3Responder→Initiator选定的 RAN Multiplier≥M2 的值、Number Chaps per Slot、Number Responder Nodes、Number Slots per Round≥NResponder4、SYNC Code Index Bitmask、Hopping Configuration Bitmask、MAC Mode指示每 block 用几个 round 和两个 round 的偏移 Ok。M4Initiator→ResponderSTS Index0起始 STS 索引、UWB Time0测距会话起始时间基准、Hop Mode KeyHOP_Key_RWk生成默认 hopping 序列的密钥、SYNC Code Index。每 block 的 round 数计算NRound 288 × N_RAN_S / (NChap_per_Slot × NSlot_per_Round)。实现建议M1-M4 这四条消息的参数最终都要落到 UWB 芯片的测距会话配置里。实现时注意三点一是 RAN Multiplier 决定测距频率门锁场景一般不需要太高频率省电但也不能太低响应慢二是 hopping 模式no hopping/continuous/adaptive选 adaptive 抗干扰最好但要实现 hopping flag 逻辑三是 STS Index0 和 Hop Mode Key 是安全相关参数必须从 URSK 派生不能硬编码。2.5 NFC 通道的 SELECT 与 AIDNFC 通道的会话建立比 BLE 简单但有 AID 选择和 FCI 解析的细节。规范要求SELECT 命令 CLA0x00、INS0xA4、P10x04、P20x00数据是 AID。锁根据手机回的 FCI 判断走 expeditedAID ...01还是 step-upAID ...02。FCI 里的 0x5C 是协议版本0x7F66 是扩展长度决定能传多大 APDU0xB7 是 User Device Descriptor厂商 ID、产品 ID、固件版本用于兼容性判断。实现建议NFC 侧实现清单注册两个 AID 的 HCE/SE applet、正确构造 FCI 响应、处理 CONTROL FLOW 的 S1/S2 状态码。注意 NFC 响应 256 字节上限大证书走 LOAD CERT 时要分块或塞进 AUTH1 的剩余空间。三、安全实现要点安全是 Aliro 的命门。门禁场景一旦被攻破物理安全直接失守。这块展开四个工程要点。3.1 密钥体系与派生Aliro 的密钥体系分两层长期密钥凭证私钥、Reader 私钥、Kpersistent和会话密钥从 expedited 阶段派生。规范要求8.3.1基础算法是 ECDSA ECC P-256 SHA-256签名 64 字节、ECKA-DH 密钥协商BSI TR-03111 §4.3X9.63 KDF输出 Kdh 32 字节、HKDF RFC 5869HMAC-SHA-256、AES-256 GCMNIST SP 800-38D做安全通道。会话密钥派生8.3.1.12 fast / 8.3.1.13 standard从 Kpersistentfast或 Kdhstandard用 HKDF 派生 160 字节。interface_byte 区分通道0xC3BLE0x5ENFC。派生出的 160 字节按偏移切分CryptogramSK0仅 fast32 字节ExpeditedSKReader0/3232 字节ExpeditedSKDevice32/6432 字节StepUpSK64仅 standard32 字节BleSK96若用 BLE32 字节URSK128若 BLEUWB32 字节salt_persistent8.3.1.13是一长串拼接x(reader_group_identifier_key) || Persistent** || reader_identifier || interface_byte || 0x5C || 0x02 || current_expedited_phase_protocol_version || x(reader ephemeral public key) || transaction_identifier || flag || 0xA5 proprietary TLV || x(Access Credential public key)。Kpersistent 在偏移 032 字节。规范要求AES-256 GCM 的 IV 构造响应用0x0000000000000001 || device_counter命令用0x0000000000000000 || reader_counter。AUTH0 的 cryptogram IV 全零。counter 每次递增不能复用。实现建议密钥派生这层最容易出错的是 salt 拼接顺序和 interface_byte 选错。BLE 通道必须用 0xC3NFC 用 0x5E搞反了派生出的密钥对不上。AES-GCM 的 counter 管理要严格counter 复用会导致密钥流重用直接破开加密。下面是密钥派生的伪代码// 规范要求从 Kpersistent(fast) 或 Kdh(standard) 派生 160 字节会话密钥 // 实现建议严格按偏移切分interface_byte 别搞错 typedef struct { uint8_t cryptogram_sk[32]; // 0, 仅 fast uint8_t expedited_sk_reader[32]; // 0/32 uint8_t expedited_sk_device[32]; // 32/64 uint8_t stepup_sk[32]; // 64, 仅 standard uint8_t ble_sk[32]; // 96, 若 BLE uint8_t ursk[32]; // 128, 若 BLEUWB } aliro_session_keys_t; void derive_session_keys(uint8_t *base_secret, // Kpersistent 或 Kdh uint8_t interface_byte, // 0xC3BLE, 0x5ENFC uint8_t fast_mode, uint8_t use_uwb, aliro_session_keys_t *out) { uint8_t derived[160]; uint8_t salt[...]; // salt_fast 用 VolatileFast, salt_volatile 用 Volatile**** // 规范要求HKDF-Extract HKDF-Expand 派生 160 字节 hkdf_sha256(base_secret, 32, salt, ..., derived, 160); // 实现建议按偏移切分注意 fast/standard 的字段存在性 memcpy(out-expedited_sk_reader, derived 0, 32); memcpy(out-expedited_sk_device, derived 32, 32); if (fast_mode) memcpy(out-cryptogram_sk, derived 0, 32); else memcpy(out-stepup_sk, derived 64, 32); if (interface_byte 0xC3) { // BLE memcpy(out-ble_sk, derived 96, 32); if (use_uwb) memcpy(out-ursk, derived 128, 32); } } // 规范要求AES-256 GCM IV 构造counter 不可复用 void build_gcm_iv(uint8_t is_response, uint32_t counter, uint8_t iv[12]) { memset(iv, 0, 12); iv[7] is_response ? 0x01 : 0x00; // 响应 0x01, 命令 0x00 // counter 放后 4 字节大端 iv[8] (counter 24) 0xFF; iv[9] (counter 16) 0xFF; iv[10] (counter 8) 0xFF; iv[11] counter 0xFF; }3.2 防中继STS 工程实现防中继是 Aliro 安全设计的核心也是 UWB 通道存在的根本原因。中继攻击原理攻击者放两个设备一个在合法手机附近收信号一个在锁附近发信号把手机的 BLE/UWB 信号转发给锁锁以为手机在边上就解锁了。BLE 信号能被这样中继因为它不测距UWB 如果只测 ToF 不带 STS理论上也能被中继攻击者转发测距信号ToF 仍能算对。规范要求Aliro 的防中继靠 UWB 的 STSScrambled Timestamp Sequence。STS 给每个测距消息加一个基于 URSK 派生的加扰时间戳攻击者转发信号时STS 的时间戳对不上因为转发有延迟且 STS 序列是加密的、攻击者无法预测下一个值。STS 的安全要求引用 CCC Digital Key Spec v4.0.0 的 section 22.1/22.2。URSK 是 STS 的根密钥TTL 12 小时STS_INDEX 最大 2^31-1。实现建议STS 实现的工程要点URSK 生命周期管理URSK 从 expedited 阶段派生偏移 128TTL 12 小时。到期、STS_INDEX 到顶、BLE 断连都要丢弃。别为了省事复用过期 URSK那是中继入口。STS_INDEX 单调递增每个测距消息 STS_INDEX 递增接收方要校验新鲜度不能比上次的小或相等。STS_INDEX 丢失比如设备重启要重新走 expedited 派生新 URSK。测距新鲜度校验不只校验 STS_INDEX还要校验 STS 时间戳在合理窗口内。攻击者即使猜中 STS_INDEX也无法伪造时间戳。URSK 不出 SEURSK 派生和 STS 计算应在安全芯片SE内完成密钥不落明文内存。3.3 配对握手与密钥存储首次配对建立信任是防中间人的关键环节。规范要求Aliro 的信任建立在 PKI 上第 6 章。Reader、Access Credential、Credential Issuer 都用 ECC P-256证书 X.509 v3 DER 编码签名 ECDSA-with-SHA256。Reader 证书要能按 profile0000 压缩附录 13.2通过 LOAD CERT 命令INS0xD1压缩后的 reader_Cert不加密传给 User DeviceUser Device 用本地存的 Reader System Issuer CA 公钥验签设 intermediate_reader_PubK。Credential Issuer 证书的 key usage 扩展只设 digital signature 位。User Authentication8.3.1.14Table 8-1 -0x01User device setting -0x02secure action规范明确 SHALL NOT 在 BLE 上指示有隐私风险 -0x03Force user authentication必须执行或终止 -0x00/0x04-0xFFRFU - Reader 在 BLEUWB 被动进入场景下 SHOULD NOT 用 0x03。实现建议配对握手的安全要点SE 安全芯片是必要的凭证私钥、Kpersistent、URSK 这些长期和会话密钥都应存在 SE 里不出芯片边界。软件实现TEE 或用户态在门禁场景风险高手机被 root 后密钥可被提取。证书链验证要完整User Device 验 Reader 证书要一路验到 Reader System Issuer CA中间任何一环失败都终止。别只验签名不验证书链容易接受伪造证书。抗时序攻击的不可区分性8.3.3.4.6User Device 返回的错误码要让外部观察者无法区分没有这个公钥还是有公钥但验签失败。实现时两条路径的耗时也要一致。防重放transaction_identifier 每次新生成16 字节真随机usage 字段 Reader/User Device 不同0x415D9569 vs 0x4E887B4C防反射。3.4 隐私不可区分性与 Dynamic TagAliro 在隐私上做了两层设计。规范要求一是上面说的不可区分性错误码和时序不可区分手机是否持有某凭证。二是 BLE 广播的 Dynamic Tag11.3.1防追踪Dynamic Tag 7 字节用 AES-128 加密Group Resolving Key对Pad_Bytes(0x000000000000) || AdvA || Expiry Timestamp加密取前 7 字节。Expiry Timestamp 是 Unix 32 位时间戳。这样广播地址随时间变化攻击者无法通过固定地址追踪手机。注意 Dynamic Tag 用的是 AES-128和访问协议安全通道的 AES-256 GCM 不是一回事。Dynamic Tag 是 BLE 广播层的反追踪机制AES-256 GCM 是访问协议层的加密通道。两者别混。实现建议Dynamic Tag 实现要点是 Group Resolving Key 的管理和时间同步。Expiry Timestamp 要准手机和锁的时间偏差大会导致 Dynamic Tag 解析失败。时间同步走 BLE 连接后的时间更新或 NTP。四、开发踩坑与兼容性这块讲实战中容易踩的坑。4.1 三通道时序依赖链这是开发者最容易出错的地方。三通道不是平行的是有严格依赖的。依赖链规范隐含BLE 发现和 L2CAP 建链必须先完成否则没有通道跑 expedited。expedited 认证AUTH0/AUTH1必须成功否则没有安全上下文UWB 测距会话起不来URSK 派生依赖 expedited 密钥材料。URSK 下发EXCHANGE tag 0x98必须完成UWB 传感器才有 STS 密钥。UWB 测距必须拿到可信距离且在解锁阈值内才能触发解锁。NFC 是 BLEUWB 都不可用时的兜底独立通道不走 UWB。实现建议状态机设计要点每个状态有明确的失败回退路径。BLE 发现失败→重试或提示用户贴 NFCexpedited 失败→终止不进 UWBUWB 测距失败→不解锁可回退要求用户显式操作。超时设计要分层BLE 发现超时、expedited 超时、UWB 测距超时各自独立别用一个全局超时。URSK 下发到 UWB 测距启动之间有窗口这个窗口里 URSK 要安全传递SE 内部或加密通道别明文走内存。4.2 跨平台兼容性不同手机厂商、不同芯片实现的差异是兼容性的主要挑战。实现建议BLE 实现差异iOS 和 Android 的 BLE 后台行为差异大。iOS 后台 BLE 限制多扫描和广播行为不同。Aliro 的无感解锁依赖后台 BLE要针对平台做适配。Android 各厂商的 BLE 栈实现也有差异尤其后台扫描间隔。UWB 芯片差异NXP、Qorvo 等 UWB 芯片的 SDK 接口不统一测距参数配置方式不同。选芯片时确认支持 FiRa 和 CCC Digital Key 要求的测距模式STS、hopping 等。不同芯片的测距精度和抗干扰能力也有差异要做实测。NFC HCE 差异Android 的 HCE 实现和 iOS 的 NFC 支持不同。iOS 对第三方 NFC applet 限制多Aliro 在 iOS 上大概率走原生钱包Apple Home Key 路径第三方 app 难直接做 HCE。FCI 协商用 FCI 里的 User Device Descriptor厂商 ID、产品 ID、固件版本做兼容性判断。锁可以根据手机的厂商/固件版本走不同的兼容路径。4.3 与 CCC 数字钥匙共存一个手机同时跑 CCC车钥匙和 Aliro门钥匙两套协议栈是预期内的共存场景。实现建议资源冲突BLE 和 UWB 是共享资源。两套协议栈同时跑时BLE 连接数、UWB 测距会话数要协调。UWB 芯片通常同时支持的测距会话数有限车钥匙和门钥匙同时测距时要排程。协议栈隔离CCC 和 Aliro 的命令框架同源都沿袭 UnifiedAccess但密码学参数不同。实现时两套协议栈的密钥、状态机要严格隔离别混用。优先级车钥匙和门钥匙同时触发时比如人走到车和门都能感应的范围要有优先级策略。这个规范没定义是厂商实现决策。4.4 常见实现错误清单实战中高频出现的错误AES-256 误用 AES-128访问协议安全通道是 AES-256 GCM别用 AES-128。Dynamic Tag 是 AES-128两者别混。interface_byte 搞反BLE 用 0xC3NFC 用 0x5E搞反了密钥派生全错。counter 复用AES-GCM 的 device_counter/reader_counter 必须单调递增复用直接破加密。URSK 过期不丢TTL 12 小时、STS_INDEX 到顶、BLE 断连都要丢 URSK留着复用是中继入口。抗时序攻击缺失查不到凭证时不走 mock 路径攻击者能通过响应时间判断手机是否持有某凭证。expedited-fast 用于纯 BLE规范明确纯 BLE 下 expedited-fast SHALL NOT 使用必须走 standard。key_slot 当其他用途key_slot 只能用于查 Access Credential 公钥规范明确 SHALL NOT 用于其他。NFC 响应超 256 字节NFC 响应上限 256 字节大证书要分块或塞 AUTH1 剩余空间。写在最后Aliro 的开发难度不在单点在三通道协作的工程整合。BLE 发现、UWB 测距、NFC 兜底三条通道各有状态机要在门口那一刻严丝合缝接起来任何一个环节时序错位要么解锁失败要么被中继打穿。如果你要上手实现建议的路径是先在 NFC 通道上把访问协议跑通最简单单通道再上 BLE加发现和 expedited最后接 UWB测距和防中继。这样每一步都能独立验证不会一上来就被三通道时序搞晕。协议事实严格以 Aliro 1.0 规范为准实现建议结合 BLE/NFC/UWB 通用开发经验。规范里没明确的芯片 SDK 调用、平台 API 细节要查对应芯片和平台的文档。Aliro 1.0 规范在 CSA 官网 all-solutions/aliro 页面可下载重点读第 8 章访问协议、第 10 章NFC、第 11 章BLE、第 12 章UWB。有用的话点个在看让更多做门禁和车钥匙的工程师看到这篇实现指南。标签Aliro · 门禁 · 数字钥匙 · UWB · NFC · BLE · 嵌入式