2.23 认证服务(0x29)——刷脸验证

一把钥匙，复制了100万次

2023年，一家汽车媒体发布了一篇引爆行业的报道：他们从一个二手诊断仪中提取出了某德系车厂的SecurityAccess密钥算法。这把“钥匙“是XOR加固定查表——任何一个逆向工程师花一个下午就能反编译出来。

问题不在于这个算法有多弱——问题在于体系结构：0x27 SecurityAccess是共享密钥体制。ECU里存着一份密钥算法，诊断仪里存着同样的算法。一旦这个算法从诊断仪端泄漏——无论是从被废弃的诊断仪、被逆向的固件、还是从离职的工程师——所有同一平台、同一密钥算法的ECU都向我们敞开了大门。

这不是一个密码学问题——这是一个密钥分发问题。

在物理完全隔离的时代（2006年），这个问题可以接受：诊断仪是昂贵而稀有的专业设备，锁在4S店的保险柜里。但在2026年——OTA远程升级已经把4S店的诊断端口变成了互联网上的一个端点——这个信任模型已经崩塌了。如果一个攻击者能通过互联网向你的网关发送正确的Seed/Key解锁序列并写入恶意固件——你需要的不再是一把更复杂的锁——你需要一个不依赖“共享秘密“的认证机制。

这就是0x29 Authentication服务的存在理由。

为什么0x29是“0x27的第二层“——对称与非对称的根本区别

0x27和0x29常被放在一起比较，但它们解决的是两个不同深度的问题：

0x27 SecurityAccess 回答的是：“你知道和我一样的秘密吗？”

Seed/Key是典型的Challenge-Response基于共享密钥——ECU生成一个随机种子，诊断仪用同样的算法算出应答。如果两个结果匹配，ECU相信诊断仪持有同样的密钥。这个机制的前提是：ECU和诊断仪都持有同一份秘密。

0x29 Authentication 回答的是：“你是谁？你属于我可以信任的组织吗？”

0x29使用基于非对称密码（PKI，公钥基础设施）的证书双向认证。ECU拥有一张由OEM（车厂）私钥签发的X.509证书，里面嵌入了ECU的唯一身份。诊断仪（Tester）同样拥有一张由OEM签发的证书。当两方建立连接时，它们互相交换证书、验证签名链、验证对方证书未被吊销——这是双向的TLS握手。

关键差异：

核心洞察：0x27和0x29的关系不是“升级替代“——它们是认证金字塔的两层。0x27是日常诊断的基础锁——快速、轻量、适合低风险操作。0x29是高价值操作的第二道保险——重量级、基于证书、满足法规要求。真正的生产级ECU不会只靠其中一个——它们在同一个诊断会话里分层协作：先用0x27解锁常规DID读写，再用0x29解锁固件签名密钥和ADAS标定区。

PKI模型——ECU的“身份证“是怎么发的

理解0x29，必须先理解背后的PKI（公钥基础设施）模型。这不像0x27的“给个种子、算个密钥“那么直观——但它才是0x29安全性的根基。

PKI信任链：

    OEM Root CA (根证书)
    │  ┌─ 私钥被物理安全存储
    │  └─ 签发下级证书
    ▼
    OEM Intermediate CA (中间CA)
    │  ┌─ 按车型/平台分区签发
    │  └─ 降低根CA泄露风险
    ▼
    ┌──────────────┬──────────────┐
    │              │              │
    ▼              ▼              ▼
  ECU证书       Tester证书      Gateway证书
  ┌─ 唯一ID     ┌─ 公司ID      ┌─ 设备ID
  ├─ 公钥       ├─ 公钥        ├─ 公钥
  ├─ 角色标识   ├─ 权限角色    ├─ 路由能力
  └─ VIN绑定    └─ 有效期      └─ 诊断端口权限

ECU证书的生产线注入：在ECU的EOL（生产线末端），OEM的密钥管理服务器为每一台ECU生成唯一的密钥对。私钥被写入ECU的安全存储区（HSM，Hardware Security Module，硬件安全模块的内嵌NvM）。公钥被打包成X.509证书并由OEM的Intermediate CA签发。这台ECU的终身身份就此绑定。

诊断仪证书的申请与授权：诊断仪制造商向OEM申请一张“诊断仪证书“。这张证书不仅包含了诊断仪的唯一标识符——还包含了OEM授予它的角色和权限范围。例如：一张“经销商诊断仪“证书可以读取故障信息但不能写固件；一张“工程开发诊断仪“证书可以有完全的读写权限。

双向验证流程（证书链校验）：

Step 1: Tester → ECU:  发送 Tester 证书链
Step 2: ECU 内部:
          a) 验证 Tester 证书的签发CA → 比对ECU内置的OEM Root CA公钥
          b) 验证证书有效期 → 未过期、未吊销（CRL或OCSP查证书吊销列表）
          c) 验证证书中的权限 → Tester是否被授权执行当前操作
Step 3: ECU → Tester:  发送 ECU 证书链
Step 4: Tester 内部:
          a) 验证 ECU 证书的签发CA → 与Tester内置的OEM Root CA比对
          b) 验证VIN绑定 → 这台ECU是否是我要诊断的目标
          c) 建立信任 → 双方确认对方身份

这就像一个双向的边境检查：你要入境（诊断仪→ECU），我要出境让别人来（ECU→诊断仪）——双方都出示护照、双方都验证护照的真伪和有效期。

0x29的请求/响应格式——一次完整的证书握手

0x29使用子功能码来区分不同的认证操作阶段。与0x27一样，子功能码编码了流程状态。

完整双向认证流程示例：

Step 1: ECU身份验证
──────────────────
Tester → ECU:   0x29 0x01 [ECU certificate request parameters]
                     SID   单向验证(请求ECU证书)

ECU内部:
  - 从HSM读取自己的私钥和证书
  - 构建包含完整证书链的正响应

ECU → Tester:   0x69 0x01 [证书数据...]
                     SID+0x40

Tester内部:
  - 用内置OEM Root CA公钥验证ECU证书签名链
  - 验证证书中的ECU身份、VIN绑定
  - 如果验证失败 → 停止后续诊断操作
  - 如果验证成功 → 进入下一步


Step 2: 诊断仪身份验证
─────────────────────
Tester → ECU:   0x29 0x02 [Tester certificate chain]
                     SID   双向验证(发送Tester证书)

ECU内部:
  - 用内置OEM Root CA验证Tester证书签名链
  - 验证Tester权限（读写等级、服务白名单）
  - 如果验证失败 → NRC（拒绝，权限不足）
  - 如果验证成功 → 进入拥有性证明阶段

ECU → Tester:   0x69 0x02
                     SID+0x40  (证书验证通过)


Step 3: 拥有性证明 (Proof of Possession)
────────────────────────────────────────
Tester → ECU:   0x29 0x03 [PoP challenge data]
                     SID   拥有性证明

ECU内部:
  - 生成一个随机挑战值(challenge)
  - 要求Tester用其私钥对challenge签名
  - 用Tester证书中的公钥验证签名
  - 签名验证通过 → 确认Tester拥有私钥

ECU → Tester:   0x69 0x03 [PoP结果]
                     SID+0x40  (私钥持有验证通过)

拥有性证明（Proof of Possession）是0x29机制中最关键的安全创新。验证证书只能证明证书本身没被篡改——但它不能证明持有证书的人是否就是证书所标识的那个实体。PoP填补了这个漏洞：你不仅要出示证书，还要用证书对应的私钥对随机挑战值签名——证明你真的持有那个私钥。

常见NRC：

• 0x31 (RequestOutOfRange) — 认证配置不存在
• 0x33 (SecurityAccessDenied) — 证书验证失败（签名不可信、证书已过期）
• 0x22 (ConditionsNotCorrect) — ECU状态不符合认证条件
• 0x10 (GeneralReject) — 认证过程中的一般性错误

0x29在UN R155/R156中的角色——从技术选配到法规强制

2022年，UNECE（联合国欧洲经济委员会）正式实施了两项改变汽车行业的法规：

UN R155（网络安全）：要求车辆制造商建立ISMS（网络安全管理系统），并为车辆设计中的每种攻击面制定防护措施。诊断接口的未授权访问被明确列为必须防护的攻击面。

UN R156（软件更新）：要求车辆制造商为OTA软件更新建立安全流程。更新包的来源验证和完整性保护是强制性的——而0x29正是ECU端验证“这个更新包是否来自授权OEM“的核心机制。

在这两项法规之下，0x29不再是一个“建议项“——它是满足法规合规的必要技术组件。

具体来说，0x29在法规合规中的角色：

1. OTA更新身份认证：在OTA服务器向ECU推送固件之前，OTA客户端（通常集成在网关里）必须通过0x29验证ECU身份——防止固件被刷入仿冒ECU或错误的目标。
2. 诊断访问授权审计：0x29的每一次证书验证都会在ECU内部产生可追溯的审计日志——哪个诊断仪（由证书唯一ID标识）、什么时间、请求了什么操作、结果如何。这满足了R155对“可追溯安全事件“的要求。
3. 权限细粒度控制：OEM可以通过证书中的权限字段控制每个诊断仪类型能执行的操作范围——而不是像0x27那样只有几个安全等级。

医院映射——从“工牌出示“到“刷脸+执照验证

0x27 SecurityAccess就像你去医院看病时，在挂号处出示你的医保卡。工作人员扫一下卡——“这是个合法的患者/医生，可以通过。“但医保卡可以被伪造、可以被盗用、可以被捡到。

0x29 Authentication就是升级版的验证流程：

单向验证(0x29 0x01) = 你看医生的执业证书。“这位医生的执照是真的——卫健委签的章——没有过期。“你验证了医院（ECU）的身份吗？还没有——这只是单向的。

双向验证(0x29 0x02) = 同时验证。“我出示了我的医师执业证书——你也出示了你的医院执业许可证。“双方确认对方身份——双向信任建立。

拥有性证明(0x29 0x03) = 指纹+虹膜+动态活体检测。“证书是你的——但你真的是证书上的那个人吗？请看着摄像头——请按指纹——好了，脸部识别匹配，指纹匹配，活体检测通过——你就是你。

在医院的最高安全区域——例如手术室血库、管制药品柜——你不会只用一张工牌。你需要密码、需要生物识别、需要主管医师的双签。0x29就是ECU安全体系中的“双签+生物识别“——它不是为了日常方便而设计——它是为了最高风险的操作而设计。

核心洞察：0x27 SecurityAccess和0x29 Authentication是认证的两层维度——前者是“你是否持有正确密钥“（what you know），后者是“你是否就是你所声称的那个实体、并且持有无法被复制的私钥证明“（who you are + what you have）。在联网汽车时代，0x29不是0x27的替代品——它是0x27之上额外的防护层。任何只靠0x27的ECU安全设计在法规合规和实际安全需求面前都是不完整的。

本篇小结

1. 0x29 Authentication 使用基于PKI的证书体系进行双向身份验证——每台ECU和诊断仪都拥有由OEM CA签发的唯一X.509证书和私钥。
2. 0x27(对称共享密钥)和0x29(非对称证书)是认证金字塔的两层——前者用于日常低风险操作，后者用于高价值、高风险操作，二者在同一诊断会话中分层协作。
3. 双向证书验证 + 拥有性证明(PoP)的完整流程确保了：对方证书可信、对方身份准确、对方确实持有对应私钥——三个安全属性缺一不可。
4. 0x29是满足UN R155（网络安全）和UN R156（软件更新）法规合规的必要技术组件——它将诊断接口安全从“技术选配“提升到了“法规强制“。
5. 证书中的权限字段使OEM可以实现细粒度的访问控制——按诊断仪类型、操作范围、有效期等多维度管控——超越了0x27安全等级的一维锁定。

【下集预告】：22个核心SID全部走完了（另有5个低频SID在2.1节已做说明）。现在，是时候把UDS从应用层放到物理载体上看了。CAN总线上8字节一帧怎么装下几十字节的诊断请求？当一帧装不下时，ISO 15765-2的多帧传输如何协同？而在百兆以太网铺进汽车的今天，DoIP又如何让UDS在TCP/IP上跑起来？传输层的故事，即将展开。