Aliro 1.0 协议技术调研：NFC/BLE/UWB 三通道架构解析

2026 年 2 月，连接标准联盟（CSA，Connectivity Standards Alliance）正式发布 Aliro 1.0 规范。这份文档编号 26-42802-001、195 页的规范，定义了一套面向"门"的数字钥匙开放标准，让手机、手表这类用户设备，用 NFC、蓝牙（BLE）、超宽带（UWB）三种无线通道去解锁门锁、闸机、车锁。

如果你做嵌入式做过门禁、车钥匙、智能锁，大概率被"每家一套私有协议"折磨过：A 厂的锁配 A 厂的 App，B 厂的卡刷不开 C 厂的门。Aliro 想解决的就是这件事，做一个厂商中立的标准，让任何合规的 Reader（读卡器/锁）和任何合规的 User Device（手机/手表）能在门口互通。

下面把 Aliro 1.0 拆成四块讲：协议基本情况、技术架构、使用场景、当前发展状态。协议事实来自规范 PDF，行业落地信息来自 CSA 官网和公开资料。

一、协议基本情况：面向"门"的数字钥匙标准

Aliro 的官方定位很明确，叫"The Mobile Access Credential Standard"（移动访问凭证标准）。它管的面很窄：只定义 Reader 和 User Device 之间怎么用数字凭证完成"开门"这件事，智能家居控制、车联网都不在范围内。

规范第 1 章把范围（Scope）写得很窄："NFC and Bluetooth LE interface between a Reader and User Device"。也就是说，Aliro 只管 Reader 和 User Device 这两端之间的接口，不管云端账号体系、不管凭证怎么签发到手机里、不管门锁的机械结构。这些上下游环节由 Credential Issuer（凭证签发方）、Access Manager（访问管理方）等角色承担，Aliro 只定义它们之间打交道的协议。

这个边界划得务实。门禁行业最大的碎片化不在硬件，而在"门口那一刻"的协议握手：手机凑近锁，双方要互相认证、要传凭证、要防中继、要兼顾没电的兜底场景。Aliro 把这一刻的协议标准化了，上下游留给各厂商自己实现，落地阻力最小。

几个关键身份需要先理清，后面技术架构会反复用到：

• Reader：读卡器侧，门锁/闸机/车锁里的那端。在 BLE 里它是 GAP Peripheral、GATT Server；在 UWB 里它是 Responder（响应测距）。
• User Device：用户设备，手机/手表。BLE 里是 GAP Central、GATT Client；UWB 里是 Initiator（发起测距）。
• Credential Issuer：凭证签发方，签发 Access Document（访问凭证），持有自己的 ECC P-256 私钥和证书。
• Reader System Issuer：Reader 系统签发方，给 Reader 签证书。
• Access Manager：访问管理方，Reader 拿不准时找它做访问决策。

注意角色分工和 BLE/UWB 的角色是反着的：BLE 里 Reader 是 Peripheral（广播方），User Device 是 Central（扫描方）；UWB 里 User Device 是 Initiator（发起），Reader 是 Responder（响应）。这个反转不是规范写错，是有意为之：BLE 阶段 Reader 要被手机发现所以它广播，UWB 阶段手机要主动测距所以它发起。开发时两套角色映射别搞混。

二、技术架构：三通道 + 两阶段 + 四部分

Aliro 的技术架构可以拆成三层来看：传输层的三通道、协议层的两阶段、信任框架的凭证体系。规范第 5 章把整个系统定义成四个部分（parts）：访问协议、传输协议、信任框架、Access Document。

2.1 三通道：NFC、BLE、BLE+UWB

规范第 9 章定义了三种传输流程，这是 Aliro 最有特色的地方：同一个访问协议，跑在三种不同的无线通道上，对应三种不同的使用姿态。

流程一：纯 NFC。手机贴一下门锁，走 ISO-DEP / T4AT / NFC-A，用 SELECT 命令（AIDA000000909ACCE5501是 expedited 通道，...02是 step-up 通道）建立会话，然后走 APDU 命令序列。这是断电兜底场景，手机没电也能用，因为 NFC 卡片模拟可以靠 Reader 的射频场供电。

流程二：BLE + UWB。这是"无感解锁"的主路径。手机在口袋里，BLE 先做发现和初始协商，建立 L2CAP 连接，跑访问协议的 expedited 阶段做互认证；认证通过后用 EXCHANGE 命令（tag0x98）把 URSK（UWB 测距密钥）下发给 UWB 传感器；然后 BLE 通知 Reader Status Completed，切换到 UWB 做精确测距，拿到可信距离后才触发解锁。BLE 负责发现和控制，UWB 负责测距，分工明确。

流程三：纯 BLE。没有 UWB 时，BLE 既做发现又做传输，但需要用户在设备上显式选择用哪个凭证（explicit user selection）：因为没有 UWB 测距，没法做无感，必须用户主动确认，否则中继攻击防不住。

为什么测距非要用 UWB 不用 BLE？这是整个架构里最关键的设计决策。BLE 的 RSSI（信号强度）能粗略估距，但精度差（米级且受环境影响大），更致命的是 BLE 信号能被中继：攻击者放两个设备，一个在车边收手机信号，一个在远处把信号转给车，车以为钥匙在边上就解锁了。UWB 用飞行时间（ToF）测距，精度到 10 厘米级，而且 STS（Scrambled Timestamp Sequence，加扰时间戳序列）让中继转发的时间对不上，物理上无法中继。"防中继"这个安全刚需，逼出了 UWB 这条通道。

2.2 两阶段：expedited 与 step-up

访问协议（规范第 8 章）把一次交易分成三步：交易初始化、expedited 阶段（必选）、step-up 阶段（可选）。

expedited 阶段是核心，目标是"用最少的命令和时间证明 User Device 持有某个秘密密钥"。它又分两种：

• expedited-standard：Reader 和 User Device 各自生成临时密钥对，用 Diffie-Hellman 协商共享密钥，再用 KDF（基于 RFC 5869 的 HKDF）派生出会话密钥。Reader 用自己的长期私钥签名临时公钥，完成对 User Device 的认证；User Device 用建立好的安全通道发自己的公钥标识和签名，完成对 Reader 的认证。这一路提供互认证、前向安全（perfect forward secrecy）、抗追踪、完整性与机密性四个特性。临时密钥意味着即使长期密钥以后泄露，这次会话内容也解不开，这就是前向安全。
• expedited-fast：用之前 expedited-standard 阶段约定好的 Kpersistent（持久密钥）直接生成 cryptogram（密文凭证），Reader 用试错法（trial-and-error）拿自己手上的多个 Kpersistent 逐个验。快，但没有前向安全，也不能直接派生 step-up 用的 StepUpSK。

step-up 阶段是可选的"加强"：Reader 在 expedited 阶段做不了访问决策时，请求 User Device 出示 Access Document（访问凭证，由 Credential Issuer 签名）。step-up 必须建立在 expedited-standard 之上，因为 StepUpSK 是从 expedited-standard 的密钥材料派生的，expedited-fast 不生成它。

这套两阶段设计的好处是分层降级：高频重复开门走 expedited-fast（快），首次或高风险场景走 expedited-standard + step-up（强）。规范明确 User Device 和 Reader 必须支持 expedited-standard，expedited-fast 是可选的。

2.3 信任框架：PKI + ECC P-256

整个安全体系建立在 PKI 之上。规范第 6 章定义：Reader、Access Credential、Credential Issuer 都用ECC P-256密钥对，证书是X.509 v3DER 编码，签名算法ECDSA-with-SHA256。Reader 证书要能按 profile0000 压缩（附录 13.2），Credential Issuer 证书的 key usage 扩展只设 digital signature 位。

这套体系和 CCC 数字钥匙（CarKey）、Apple HomeKey 是同源的。kormax/aliro 的研究指出，Aliro 命令集"largely follow UnifiedAccess protocols such as CCC CarKey and Apple HomeKey, but with different cryptography"。也就是说 Aliro 复用了 CCC 那套 APDU 命令框架（SELECT、AUTH0、AUTH1、LOAD CERTIFICATE、EXCHANGE、CONTROL FLOW），但密码学参数和部分能力做了重新定义。这让它能站在 CCC 已经验证过的工程基础上，又保持自己的独立性。

凭证体系支持离线场景：Access Document 是 Credential Issuer 签名的签名数据，Reader 即使不联网也能验签做访问决策；同时支持 Revocation Document（吊销文档）做凭证撤销。这对门禁很重要，很多门锁离线运行，不能依赖实时联网验凭证。

三、使用场景：从车锁到智能家居

Aliro 的"门"是个广义概念，规范和 CSA 官方资料里反复出现的场景有四类。

车锁（数字车钥匙）。这是最早驱动这套技术成熟的场景。CCC（Car Connectivity Consortium）的 Digital Key 规范已经做到 4.0.0，Aliro 规范大量引用 CCC Digital Key Spec v4.0.0，UWB 的 MAC、PHY、安全（STS）直接引用 CCC 规范的 section 20/21/22。可以说 Aliro 的 UWB 部分基本是 CCC 数字钥匙那套测距技术的"门禁版"移植。车锁场景的核心需求是防中继（Relay Attack 是车钥匙最经典的攻击）和无感（人走到车边自动解锁），这正好对应 BLE+UWB 流程。

门禁（商业与住宅）。CSA 官方把市场分成 Commercial（商业）和 Residential（住宅）两块。商业门禁强调多厂商互通：一栋写字楼里不同厂商的闸机、不同品牌的手机，靠 Aliro 实现互通。住宅场景强调"用手机/手表代替物理钥匙"的无感体验。CSA 新闻稿里提到 Durin 这家厂商在做"Hands-Free Access to Every Door"，Samsung SmartThings 也在接入，都是门禁方向的落地。

工牌/企业凭证。手机当工牌刷卡进办公区，本质是门禁的子场景，但更强调凭证的集中签发与吊销（员工离职要立刻吊销凭证），对应 Access Document + Revocation Document 那套机制。

智能家居。Apple Home Key、Samsung Wallet、Google Wallet 三大钱包生态已确认支持 Aliro（CSA 官方原话："confirmed commitment from the world's leading mobile wallet ecosystems"）。这意味着以后用 iPhone、三星手机、Pixel 手机的原生钱包就能当门钥匙，不用装厂商 App。这是 Aliro 最大的落地杠杆，直接借力三大手机厂商的钱包分发渠道。

NFC 在所有场景里都是"最后防线"。手机没电关机了，NFC 卡片模拟靠 Reader 射频场供电还能刷，这是 Apple Home Key 一直在宣传的"power reserve"特性，Aliro 把它标准化了。对门锁厂商来说，这意味着即使无感解锁（UWB）失效，NFC 还能保证用户进得了门，不会因为手机没电被锁门外。

四、当前发展状态：1.0 刚落地，生态起步

规范版本。Aliro 1.0 于 2026 年 2 月 26 日由 CSA 正式发布（规范文档日期 2026-02-18），文档编号 26-42802-001，195 页。CSA 官方称这是"living standard"（活标准），不是一次性发布，未来阶段会扩展安全密钥共享（secure key sharing）等用例，并保持向后兼容。

联盟与生态。Aliro 由 CSA 主导。这个联盟 2002 年成立（前身是 Zigbee 联盟），也是 Matter 智能家居标准的母组织。Aliro 的核心生态支撑是三大移动钱包：Apple、Google、Samsung 已确认支持。这是 Aliro 区别于其他门禁标准的关键，它不是某个门锁厂商的自有协议，而是被三大手机操作系统原生钱包背书的开放标准。

与 CCC 的关系。这是理解 Aliro 技术来源的关键。CCC（Car Connectivity Consortium）的 Digital Key 规范是车钥匙领域的事实标准，已经迭代到 4.0.0。Aliro 在 UWB 层面大量复用 CCC Digital Key Spec v4.0.0 的 MAC/PHY/Security 定义（规范里直接引用 section 20/21/22），命令框架也沿袭 CCC CarKey 和 Apple HomeKey 的 UnifiedAccess 路径。可以理解为，CCC 数字钥匙是车场景的成熟方案，Aliro 把这套方案"通用化"到门禁场景，两者技术同源、场景互补。一个手机同时跑 CCC（车钥匙）和 Aliro（门钥匙）两套协议栈是预期内的共存场景。

落地情况。截至 2026 年 8 月，Aliro 处于"规范发布完成、进入认证与商业化阶段"（CSA 原话："As the specification enters the certification and commercialization phases"）。公开可见的落地信号包括：三大钱包生态确认支持、Durin 等门锁厂商宣布接入、Samsung SmartThings 接入。但具体认证产品清单、首批商用门锁型号，CSA 尚未公布完整名单。这部分信息基于公开资料整理，非官方统计，具体产品上市时间以厂商公告为准。

还有个现实情况：Aliro 1.0 规范本身公开可下载，但完整工程落地还要看三大钱包的 SDK 开放程度、UWB 芯片厂商（NXP、Qorvo 的 FiRa 兼容芯片）的支持、以及门锁主控厂商的集成进度。现在正是"规范就绪、生态在搭建"的窗口期，先吃透协议栈的工程师，后面门禁数字化起来会占先手。

写在最后

Aliro 的技术并不全新，它的三通道（NFC/BLE/UWB）、PKI 凭证体系、APDU 命令框架，在 CCC 数字钥匙和 Apple HomeKey 里都跑通过。Aliro 的真正价值在于把这些已经验证的技术固化成一个厂商中立的开放标准，并用三大钱包的生态背书解决"门口互通"这个几十年没解决的问题。

对嵌入式工程师来说，Aliro 值得关注三点：一是三通道协作的工程复杂度（BLE 发现、UWB 测距、NFC 兜底的时序与状态机），二是防中继攻击的 UWB STS 机制，三是与 CCC 数字钥匙共存的多协议栈工程。这些会在下一篇《Aliro 协议开发规范指南》里展开讲实现细节。

如果你正在做门锁、车钥匙、企业门禁，Aliro 1.0 规范值得下载来读，尤其是第 8 章（访问协议）、第 11 章（BLE）、第 12 章（UWB）。规范地址在 CSA 官网 all-solutions/aliro 页面。

有用的话点个在看，让更多做门禁和车钥匙的工程师看到这个新标准。

标签：Aliro · 门禁 · 数字钥匙 · UWB · NFC · BLE · 嵌入式