对广芯微车钥匙PKE方案的深入学习总结
date
Dec 7, 2024
slug
2024-12-07-the-unicmicro-PKE-solution-in-depth
status
Published
tags
汽车电子
type
Post
AI summary
summary
本文对广芯微电子提供的PKE方案进行了完整的分析，重点整理出来在基站和钥匙端进行的LF以及HF通信的工作流程。
之前在另外一片笔记中，我对目前汽车电子领域中的主流无钥匙进入解决方案（RKE/PKE/PEPS）进行了总结，在本文中重点针对国产广芯微电子所推出的一整套PKE解决方案的完整工作原理进行更细致的描述，增强对PKE技术实现的更深入理解。
广芯微电子的PKE完整方案
所有的无钥匙进入方案大致都是如此，分为两个部分，钥匙端和安装在车辆（既包括汽车，也包括两轮电动车）内部的基站端。总体来讲，钥匙端因为使用纽扣电池供电，所以对各种应用场景下的功耗极其敏感；而基站端是提前安装到车辆内部，是由车辆的蓄电池供电，这一点是整个方案设计的基础。否则如果不考虑钥匙端功耗的话，整个方案完全可以大幅度简化。例如手机上的蓝牙车钥匙功能，不需要考虑手机端的蓝牙功耗，那么只需要通过蓝牙或者NFC就可以实现这个无钥匙进入系统了，系统设计更简单，通信的安全性还更好，但是蓝牙的功耗是纽扣电池供电的PKE钥匙端无法承受的，所以采用了这样的RFID LF+433MHz HF通信的模式。
从通信的角度上，钥匙端和基站端都有低频LF和高频HF两个部分，其中LF部分一般采用RFID的125KHz，HF则可以采用433MHz或者2.4GHz进行通信。
- 基站端通过LF向外发出信号，LF没有接收功能；通过HF等待接收钥匙端的信号，没有发送HF信号的功能。
- 钥匙端刚好相反，通过LF接收信号，但是不具备LF发送信号的功能；而需要向车辆发送的控制信号则从钥匙端的HF发射器发出，钥匙端的HF部分没有接收功能。
其实对于通信的HF部分，绝大多数情况下两端的HF实际上都处于sleep的状态。只需要在被唤醒的时候打开TX或者RX进行通信即可。所以HF的技术选型并不是很重要，例如在以上的架构图中既可以选用Sub1G频段的433MHz，也可以使用常用的2.4GHz。为了尽可能降低钥匙端的功耗，HF部分的设计一般是单向的收发关系，钥匙端固定是HF的发射器，通过这个发射器向基站端发出车门的控制指令；而基站端是固定的HF接收器，固定的接收来自钥匙端的控制信号。既然是这种单向的收发关系，应对中继攻击、中间人攻击这类破解手段就难以有合理的技术手段，因此这样的方式其实是存在一定的安全性隐患。如果HF设计为双向通信，通信的安全性方面倒是可以有效的改善，但是通信过程中两端HF的TX和RX要始终保持打开的状态，这对于低功耗设计尤其是纽扣电池供电的钥匙端无疑是一个非常大的挑战。因此这种HF端的单向收发算是在安全性和功耗方面的一个折衷设计。
HF端通信的逻辑相对比较简单，就是钥匙端在被唤醒（LF RFID扫描唤醒或者钥匙端的按键唤醒）时通过HF发射器向基站端发出一条指令即可。因此整个系统设计方案的关键实际上在于LF部分。
基站的LF发射流程
基站端的LF部分的电路包括MCU和一个125KHz信号的发射器UM12020D。
广芯微的UM12020D 用于驱动125KHz低频天线，峰值输出电流 5A，连续输出电流可达 3A，最高工作电压 38V。通过输入端 IN1、IN2 输入 PWM 控制信号，可驱动低频天线。芯片内部集成同步调节电路可以降低PWM控制过程中的功耗。
UM12020D与MCU之间连接的典型参考设计如图所示。
- OUT1与OUT2引脚之间连接125KHz的发射天线，IN1和IN2连接MCU端的PWM引脚，nSLEEP引脚连接MCU的GPIO用于控制OUT的输出。
- 使用nSLEEP引脚可控制 LF 驱动芯片 UM12020D 进入工作状态或休眠状态。当驱动芯片处于工作状态，INA、INB引脚的互补 PWM 信号可以驱动 UM12020D 将数字信号转换成模拟信号。当驱动芯片处于休眠状态，即使 INA、INB脚输入互补 PWM 信号，UM12020D 也不会进行模拟信号调制。后续就可以利用这个特性把要发给钥匙端LF的信号调制到125KHz的载波信号中。
MCU向IN1和IN2两个引脚输入两路反向互补的125KHz PWM信号，这个125KHz的PWM周期性信号就是载波。真正要通过载波发送给接收端的实际数据通过控制nSLEEP引脚来发出。
本质上以上的UM12020D电路实际上就是一个ASK调制信号驱动器，具体的使用中在IN1和IN2输入稳定的125KHz PWM作为ASK的载波信号，以nSLEEP信号作为ASK的调制波。实际要发出的数据就包含在调制波信号上。对于ASK调制的原理参考下图就比较清楚了：
- s(t)就是在nSLEEP上输出的调制波信号，载波就是在IN1和IN2上同时输入的反向互补的125KHz的PWM波。
当要通过LF发送给钥匙端的调制波信号是1KHz的情况下，只需要以1ms为单位控制nSLEEP引脚为0或者1即可。
通过nSLEEP引脚向钥匙端发出的LF信号应进行通信数据帧格式的配置。配置用户数据帧中前导码长度、匹配码数据、用户数据等内容，方便在接收端进行解析。
钥匙的LF接收流程
在以上钥匙端的系统设计方案中，主要包含了一个内置125KHz接收功能的UM2082F08的低功耗MCU和一个HF的发射器。广芯微也有一个独立的125KHz Reciver的芯片系列UM2020，因此也可以使用这个独立的125KHz Reciver芯片跟任意的低功耗MCU配合来一起实现UM2082F08的功能。
低功耗MCU的功能相对比较简单，以下以UM2020为例来解释125KHz接收端的工作流程。
UM2020 是一款三通道、超低功耗的 ASK 接收芯片，可检测 30 ~ 300KHz 范围的 LF（低频）载波频率数据并触发唤醒信号，唤醒之后 MCU 可通过 IO 实时采集后续接收到的数据，也可以通过SPI 或 I2C 直接从寄存器读取（最长保存 8 字节数据）。
UM2020基于RFID的125KHz的工作原理工作，整个钥匙端处于深度休眠的状态，当基站端周期性发出125KHz扫描信号时，UM2020的LF接收电路会被唤醒，在UM2020进行初步的数据接收和判断以后，把接收到的数据缓存在UM2020的buffer中，确认是自己的基站端发出的扫描信号的情况下，UM2020会通过其Wake pin唤醒钥匙端的低功耗MCU，低功耗MCU端通过SPI或者I2C引脚读出UM2020缓存的数据信息，进行进一步逻辑判断后，再打开钥匙端的HF模块向基站端发出解锁或者加锁的指令。
因此钥匙端设计整个中心在于其LF接收电路，而LF接收电路的核心则在于UM2020.
基于UM2020的电路设计参考图如下：
- 其中LFP1，LFP2，LFP3连接一个125KHz的三向天线，采用三向天线的原因是对于各个方向的接收感应灵敏度的问题，确保任意方向上都能接收到较好的感应信号。
- MCU和UM2020可以通过SPI或者I2C进行数据端的连接，用于对UM2020进行配置，以及从UM2020的缓存buffer中读取其接收到的数据。
- UM2020通过其Wake引脚在接收到数据后唤醒MCU。
LF的唤醒对码过滤功能
对于以上工作逻辑的理解，存在的两个问题：
- 如果所有的车辆都使用类似的125KHz进行类似的扫描的话，这也就意味着每次UM2020都会被唤醒，UM2020再进一步唤醒MCU，那么在一个停车场，很多车辆都同时周期性发出125KHz扫描信号的话，UM2020和MCU被频繁唤醒，对于钥匙端的低功耗是一个非常大的问题。
- 同样的逻辑，如果同时有多个车辆周期性发出125KHz的扫描信号，对于钥匙端而言，如果判断是自己车辆的信号，只有接收到自己车辆信号的时候才会发出解锁信号。
以上两个问题都可以通过UM2020上的对码过滤功能在很大程度上解决。
UM2020的125KHz信号的接收和唤醒流程中有一个对码检测模式。所谓的对码实际上是一个16bit的数据。在LF通信的过程中，基站端周期性发出125KHz的扫描信号，这个扫描信号大致包含载波、对码以及8个字节的数据三部分。钥匙端和基站端可以通过对码数据和8字节数据中的部分数据来验证这个信号是否是自己车辆所发出的信号。不同的地方在于，对码数据的检测和对比直接在UM2020中自动检测，而如果要依赖于8字节数据部分的解析，则需要把MCU唤醒，在MCU的执行逻辑中读取数据并进行解析和判断。
钥匙端会在接收到125KHz载波信号时被唤醒，开始接收对码，当接收到的对码数据与自己内置的对码数据不一致时，UM2020重回监听模式，不去唤醒MCU；而如果对码一致的情况下，则唤醒MCU，在MCU上通过SPI或者I2C读取数据，对读取的数据进行进一步的解析判断，决定该数据是否是自己的数据，以及是否需要通过HF向基站端发出解锁信号。
通过以上所描述的对码检测以对接收数据的解析和判断，就可以解决频繁唤醒带来的功耗问题，以及判断是否是自己车辆所发出信号的问题。
两端的HF通信流程
HF部分的通信逻辑比较简单，完全受LF端接收数据事件的驱动：
- 基站端每次周期性的发出125KHz扫描信号后，都会同时把HF的RX打开一段时间，等待接收来自钥匙端的HF信号，如果能够接收到钥匙端发出的信号，表示钥匙就在附近。
- 而钥匙端则在LF部分接收到自己车辆所发出的125KHz扫描信号的情况下，通过MCU控制HF部分向基站的HF接收器发出一条指令，告知基站端自己就在附近。
HF通信的安全性隐患
对于HF端的通信而言，钥匙端是单发功能，基站端是单收功能。这种通信模式没有办法很好的应对中间人的重放攻击。
例如在国外网站上看到的典型偷车案例，钥匙在家里，车辆在户外，本来这个距离的情况下，车辆上的基站信号扫描不到钥匙的位置，钥匙也就不会发出HF信号去控制车门开锁。但是如果一个中间人在家门口使用一个同时有LF收发+HF收发的攻击设备，在这个攻击设备上接收来自基站的125KHz扫描信号，把这个信号的功率放大以后再发射出去，这个信号就会被室内的钥匙端收到，钥匙端检测这个信号来自于自己的车辆，就会通过自己的HF向外发出解锁的信号，这个解锁的信号会被攻击设备的HF接收端捕获，再次放大以后发给车辆基站的HF Receiver，基站就会认为钥匙就在附近从而控制开锁，盗贼就可以堂而皇之的把车门打开。
这个问题对于以上PKE方案几乎无解，根源还是在于，为了尽可能降低功耗，HF通信的设计是单向收发的，通信双方缺乏有效的手段去验证对方身份的合法性。如果采用蓝牙这类双向具备身份认证机制的通信方式，这个问题就可以得到完整的解决。
参考资料：
- 广芯微电子PKE 评估开发套件应用手册
- UM2020数据手册
- UM2020用户手册
- UM12020D数据手册