UDS诊断SecurityAccess（0x27）安全访问机制与NRC速查指南

1. SecurityAccess并不是“防盗锁”，而是诊断权限的闸门

1.1 27服务保护的是哪一层

做UD S诊断的人，几乎每天都在跟一串SID打交道：10会话控制、19读取DTC、22按ID读数据、2E按地址写数据、27安全访问、28通信控制、31例程控制、34/36/37刷写流程……但很多人对27的理解其实停留在“发个密钥就能解锁”的层面。真正在测试台架或实车上排查问题的时候，才发现它跟整车状态、会话控制、时序要求、尝试次数全部绑在一起，报错的时候连0x35、0x36、0x37都分不清。

SecurityAccess，也就是ISO 14229-1里定义的0x27服务，从名字上看是“安全访问”，但它保护的并不是整车的防盗锁，而是ECU内部一类“受限制的诊断功能”。大家可以这样理解：诊断仪跟ECU之间的普通对话，比如问一下软件版本、读一下故障码，属于对外开放的窗口；而写数据、标定、刷写程序、执行某些特殊例程，属于需要权限的内部房间。27服务就是那把进入内部房间的钥匙，准确地说，是“验证诊断仪是否有资格拿到钥匙”的门禁系统。

UDS诊断协议把诊断服务分成了几大类：10、3E这类负责通信和会话状态管理；19、14这类负责DTC的读与清；22、2E这类负责数据读取和写入。27服务属于“access”类别，专门负责权限控制。它在整个uds诊断流程里的位置非常特殊——不能直接产生业务效果，但没有它的许可，很多业务效果根本无法触达。打一个不精确但好记的比方：19服务是“你去查一下告警记录”，27服务是“你先证明你有权限去查告警记录”。前者是业务，后者是安全边界。

我在实际项目里见过不少新入行的同事，上来就对着诊断调查表找“27=SecurityAccess”，然后直接往报文里塞种子、密钥。等到ECU回一个7F 27 35，才发现自己连安全等级对应的子功能都还没理清楚。所以说，这份速记笔记首先要解决的不是“怎么发送27”，而是“27服务到底立在哪个环节、它后面托管了哪些权限”。

1.2 过了27服务才能碰哪些服务

要判断一个诊断功能是否需要先过27服务，最直接的办法是去读ECU的诊断规范或ODX文件，而不是靠猜。但大体上可以按风险来分级：凡是“只读不写”的，普遍不需要安全访问；凡是“会改变ECU内部状态、需要掉电保存、可能影响车辆行为”的，大概率需要安全访问。

举几个最常见的例子：22服务读VIN、读序列号、读版本号，基本不受27保护；2E服务写VIN、写配置字、写生产参数，通常会要求先完成安全访问；31服务里的例程控制，比如“擦除Flash”“复位DTC”“执行自学习”，是否要求安全访问，取决于例程编号对应的功能；34/36/37这一组刷写会话，几乎必然要求先通过安全访问，否则ECU不会接受下载请求。

还有一个容易被忽略的点：刷写或标定过程中，27服务通常不是只过一次，而是可能要按不同安全等级过多次。比如某些ECU在扩展会话下先做一次安全访问，允许写普通参数；进入编程会话后，又会用另一个安全等级验证刷写权限。这两个等级对应两个不同的子功能对，密钥算法也可能完全不同。

所以，我平时看诊断需求时，习惯先把“哪些服务需要解锁”列成一张矩阵。矩阵左边是SID和服务名，右边是安全等级、对应子功能、是否需要非默认会话、是否限定物理寻址、超时要求。这张矩阵看起来简单，但能有效避免“代码里把27写死成01/02，结果遇到需要05/06的控制器直接失败”这种低级事故。

1.3 安全等级与“一把钥匙开一把锁”

ISO 14229-1并没有规定ECU内部必须划分多少个安全等级，它只提供了等级编号的编码规则。实际项目实施中，OEM通常会根据产品需求自行定义：有的ECU只有一个等级，只要过了一道门后面都通；有的ECU把参数写入、例程执行、刷写分别划到不同等级，每个等级必须单独解锁。

这里的编码规律先记住：奇数子功能用于请求种子，偶数子功能用于发送密钥。也就是说，0x01/0x02是一对，0x03/0x04是一对，0x05/0x06是一对，0x07/0x08又是一对。每一对对应一个安全等级。

安全等级高低并不一定按数字大小排，0x05/0x06不一定比0x03/0x04权限更高，这完全是OEM内部定义。有些ECU把0x01/0x02作为普通标定解锁，0x03/0x04作为Bootloader刷写解锁；也有些ECU反过来。所以不要在国内A项目里习惯了“01去请求种子、02发密钥”，就直接套用到B项目的ECU上，还是要查对照表。

在uds诊断中信息安全相关的讨论里，经常有人纠结“种子是随机数吗”“如果种子可预测，安全访问不就形同虚设吗”。严格说，标准没有强制种子必须真随机，它只要求“使访问者无法通过简单重放上一次的响应来获得访问权限”。很多ECU在开发阶段为了便于台架测试，甚至会用固定序列或与时间相关的伪随机数作为种子。而在量产ECU里，种子通常由硬件安全模块生成，至少保证每次上电后的数值序列不可预测，防止攻击者直接录一段“27 01抓种子、27 02回密钥”的报文反复播放。

我一直跟团队强调一句话：27服务解决的是“授权入口”问题，而不是“绝对防盗”问题。真正的密钥算法、密钥存储、算法运行环境，才决定这套uds诊断信息安全体系的上限。车载诊断开发里，千万不要把SecurityAccess当成银弹。

2. 一次握手的完整速记：种子当考题，密钥当答卷

2.1 先记死请求格式：27 + 子功能

UDS诊断协议里的27服务，报文格式非常短，核心就是“SID + SubFunction + 数据”。随便翻一下ISO文档就能看到，27这个服务没有7F之外的正响应条件，也不需要像31服务那样先定义一个例程编号再决定后续长度。

请求种子时，诊断仪发出的诊断请求通常是：

text复制27 01

其中0x27是服务ID，0x01是子功能，表示“请求安全等级为1的种子”。如果ECU认为当前条件允许，它会回复：

text复制67 01 1A 2B 3C 4D

0x67是正响应SID，等于请求SID加0x40，这是UDS协议的统一特征；第二个字节是子功能回显，仍为0x01；后面的1A 2B 3C 4D就是ECU给出的种子数据。种子长度并不是固定的，常见的有2字节、4字节，也有部分ECU用更长或者更短的种子，具体定义以车型的诊断规范为准。

发送密钥时，报文变成：

text复制27 02 9E 81 76 90

0x27是服务ID，0x02是子功能，表示“发送针对安全等级1计算出来的密钥”，后面的数据就是计算后的密钥。ECU计算正确，会回复：

text复制67 02

到这里，正响应结束，后续就可以执行那些受安全访问保护的服务了。注意，密钥的正响应往往没有其他数据，不像请求种子那样会带一串随机数据回来。这个细节虽然不起眼，但在解析报文时很关键，很多测试脚本没有考虑“67 02不带数据”的情况，直接把响应当成定长解析，最后把下一帧报文错位处理。

2.2 请求种子、发送密钥这两步到底怎么走

先讲一条看似多余、但实际最容易出错的顺序：必须先请求种子，再发送密钥。任何情况下，密钥不能凭空生成，也不应该在没有收到当前种子时直接发送预存密钥。

握手过程可以摊开来分四步看：

第一步，确认诊断会话。大多数ECU要求27服务在非默认会话下执行，所以在发27之前通常要先发“10 03”进入扩展会话，或者“10 02”进入编程会话。

第二步，发送请求种子指令，比如“27 05”。这里05是对应安全等级的“请求种子”子功能。ECU收到后，如果条件满足，就给诊断仪返回一串当前生效的种子数据。

第三步，诊断仪拿到种子后，在外部完成密钥计算。这个计算过程不是UDS标准的一部分，而是OEM或ECU供应商自定义的算法。算法输入至少包含种子，通常还包含一个“密钥盐”或者厂家内部参数，输出就是对应等级的密钥。

第四步，发送密钥指令，比如“27 06”，后面拼接计算得到的密钥字节。ECU内部重新计算一遍并比对，一致就返回“67 06”，不一致就返回否定响应码。

在实际的车载测试系统里，这四步往往会被封装成“SecurityAccessUnlock(level)”这样的函数。函数内部完成了从会话切换、种子请求、调用密钥算法、密钥发送到判断正响应的全部逻辑。这样做的目的不是为了省事，而是为了避免测试用例作者在编写过程中把握手顺序写乱。

有一个必须牢记的细节：种子是一次性的，或者说只在当前这一轮握手内有效。发完密钥之后，无论成不成功，如果需要再次进入安全状态，一般都要重新走一遍“请求种子—计算密钥—发送密钥”的流程。不要把上一轮收到的种子存起来，等到几分钟后ECU已经换了个会话状态再拿旧种子去算密钥，这种“复用老种子”的做法在很多ECU上会直接报0x24或0x37。

2.3 子功能奇偶规律和安全等级的记忆方法

我一直用一套“奇偶速记法”来记27服务的子功能。

先写一句话：奇数是发问，偶数是回答。这句话的含义是：奇数子功能用于向ECU发问：“请给我种子”；偶数子功能用于向ECU回答：“这是我的密钥”。

对应的子功能对是这样的：

看到这里，敏感的人已经注意到了：子功能编号本身不是“1、2、3、4”连续递增，而是按“01/02、03/04、05/06”这样成对跳着排的。这是ISO 14229-1故意留出的编码手段，目的就是把“请求种子”和“发送密钥”清晰地配对。所以以后不管看到0x11、0x12还是0x15、0x16，只要记住“奇数请求种子，偶数发送密钥”，就不会把报文发错。

还有一个需要特别注意的边界：0x00、0x80以及更高的一些编号属于保留或特殊定义，不能随便当作安全等级来用。实际项目中，安全等级一般不会超过0x7F的范围。具体的可用等级编码、每个等级在什么条件下生效，全部要以ECU的诊断调查表（Diagnostic Spec）为准。我在项目里见过把0x14当成子功能直接用的情况，结果ECU回了一个0x12“子功能不支持”，实际上人家定义的等级根不是这一组。

2.4 算法的边界：标准里不写，但流程里必须约好

ISO 14229-1只规定了27服务的请求、响应和否定响应码，它从头到尾没有规定种子必须是几个字节，也没有规定密钥算法应该用AES还是用查表法。这些都留给了OEM或ECU供应商。

这一块在实际合作中容易踩坑。诊断仪供应商拿到的是“密钥算法描述”“密钥算法DLL”“安全访问授权码”之类的材料，而ECU端则是把算法运行在安全核或者硬件安全模块里。两边如果不在种子长度、字节序、密钥长度、有效等级上对齐，哪怕算法公式完全一致，最终算出来的密钥也一定对不上。

我在集成测试阶段最常遇到的情况是这样的：A部门说“种子是4字节”，B部门在诊断描述文件里写成了“种子长度4”，但密钥算法例程实际读取的是“高字节在前”的种子，而诊断仪端默认按低字节在前去组包，一比对当然失败。这种问题不涉及密码学破解，纯粹是设计和实现之间的对齐问题，但排查起来却很费时间。

所以，做27服务相关开发时，文档里至少要明确以下几点：种子长度、密钥长度、字节序、子功能号、支持的会话、允许尝试次数、解锁后持续有效条件、回复延迟要求。这些信息看起来琐碎，但每一条都对应实际测试中可能遇到的否定响应码。

还有一条来自项目现场的教训：涉及密钥算法的代码不要随便交给第三方工具链公司“优化”。安全访问的算法属于整车信息安全敏感内容，尽管我们这里不谈破解，但必须意识到，一旦算法被泄露，整套uds诊断安全访问体系就形同虚设。量产项目里，种子生成和密钥校验都应当尽量放到安全硬件里执行，不要让ECU的普通应用程序直接暴露密钥明文和校验逻辑。

3. 27服务NRC速查：别看到7F就慌

3.1 先分清：否定响应码的返回格式就是 7F + SID + NRC

如果诊断仪发送的27请求没有被ECU接受，ECU不会保持沉默，而是会回一帧带有否定响应码的报文。格式很简单：

text复制7F 27 NRC

0x7F是UDS的否定响应服务ID，中间的0x27表示是27服务在拒绝，最后的NRC就是具体原因。所以测试日志里看到的“7F 27 37”，本质上是说“27服务拒绝了这次请求，原因是0x37”。

很多测试人员拿到“7F 27 37”后习惯直接截图发群，然后问别人“这是什么意思”。但厉害一点的技师会先对NRC表，再结合当前ECU状态去判断原因。日志里的否定响应码只是线索，不是最终答案，因为同一个NRC在不同的ECU、不同的项目上，背后的触发条件可能有差异。

如果要用一句话概括NRC排查思路：先看是“格式问题”“状态问题”还是“时序问题”，再沿着这个类别去找自己刚才发的那几帧报文记录。

3.2 一张表记住SecurityAccess常见NRC

下面这张表我建议直接保存下来，遇到27服务报错时优先对着看：

这张表在绝大多数项目里够用。你只要把NRC从0x12到0x37挨个对一遍，基本就能定位出是配置问题还是状态问题。

有一点要注意：0x33在27服务自身的回复里相对少见，更多时候出现在2E、31、34这些服务上。例如，一个ECU已经解锁到安全等级1，但某些高权限的写服务要求安全等级2，此时去尝试执行写操作，ECU很可能回“7F 2E 33”，而不是“7F 27 33”。所以看到0x33时，不要只看27服务，还要检查当前安全访问等级是否满足目标服务的要求。

3.3 NRC 0x35、0x36、0x37的底层区别

这三个NRC是27服务最容易混淆的三兄弟。我见过很多测试报告里把“7F 27 37”写成“密钥错误”，这是不准确的。0x37的意思是“时间延迟还没结束”，而不是“密钥不对”。真正表示密钥不对的是0x35。

具体区别可以这样理解：

0x35是“这次算错了”。ECU把接收到的密钥和内部计算值比对后，发现不一致，于是拒绝。此时如果你迅速修正算法、重新请求种子并发送正确密钥，还是有机会成功的。

0x36是“错太多次了，暂时不让你试了”。安全访问机制里通常会设置一个最大尝试次数，比如3次或者10次。超过次数后ECU会拒绝继续验证，甚至可能要求整车断电或等待更长时间才会复位。

0x37是“你太急了，时间还没到”。一些ECU在安全访问失败后，会启动一个延迟定时器，规定在N秒之内不能再次进行安全访问请求。这个机制跟0x36的区别在于：0x36表示次数已经用尽，0x37表示单次请求之间的最小间隔还没满足。

我举个例子：某ECU规定，一次错误密钥之后需要等待10秒，如果测试脚本在失败后立即重试，第二次发送相同密钥时虽然算法对了，但ECU仍会回0x37，因为10秒还没到。很多自动化测试脚本在这里就会不停循环重试，结果越试越失败，最终把尝试次数耗尽变成0x36。

解决这类问题有一个通用套路：解析到0x37后，插入延时等待，通常5秒、10秒甚至30秒，依据诊断规范来定；解析到0x36后，则不要继续在同一轮上电状态里重复尝试，最稳妥的办法是给ECU重新上电，让安全访问尝试计数器和延迟计时器复位。

3.4 一段日志判断的现场示范

我再写一段类似实车测试日志的伪报文，演示一下判读过程。假设诊断仪发的完整序列是：

text复制发送: 10 03
接收: 50 03
发送: 27 05
接收: 67 05 4A 15 C2 9D
发送: 27 06 7C 3E 9A 17
接收: 7F 27 35

如果只看最后一帧，“7F 27 35”表示密钥无效。但密钥无效有很多可能：种子少取了一个字节、密钥算法版本不对、字节序反了、密钥长度错误。这时先检查你对种子的拼包逻辑：ECU返回的是4A 15 C2 9D，你拿去参与计算时，是当4A 15 C2 9D还是9D C2 15 4A？如果诊断规范里没有特别说明，一般按原始顺序处理，但有些平台要求高字节在前，有些则相反。这类问题靠读日志就能发现，不一定真要去查密钥算法。

再换一个场景，如果报文变成：

text复制发送: 10 03
接收: 50 03
发送: 27 05
接收: 7F 27 22

这个“0x22条件不满足”其实就是告诉你：在目前的状态下，ECU不认为你有资格请求种子。最可能的问题是ECU没有真正进入允许27服务的会话，或者当前整车条件不满足，比如点火状态不对、挡位不在P挡、存在未完成的例程。遇到0x22，不要急着算密钥，先问两个问题：当前会话是什么？前一条诊断指令有没有被ECU正确执行？

4. 状态联动才是真正的坑：默认会话、扩展会话、3E保活

4.1 先换会话还是先解锁

这个问题看似简单，但是在实际项目里反复出错。很多ECU要求27服务必须在非默认会话下执行。如果你刚上电就直接发“27 01”，ECU默认处于默认会话（10 01对应的状态），此时回复很可能是“7F 27 22”，条件不满足。

所以最稳妥的调用序列是：

text复制10 03  进入扩展会话
50 03  ECU确认进入扩展会话
27 05  请求种子
67 05 ...  返回种子
27 06 ...  发送密钥
67 06  解锁成功

有些ECU也允许在默认会话下直接执行27服务，但从我看到的大量项目来看，限制在非默认会话是主流做法。即使诊断规范里没有写明，先发一条10 03再执行27通常不会造成坏影响。唯一的例外情况是，在编程会话（10 02）下某些ECU只接受bootloader自己的安全等级，不接受扩展会话里那套等级，这时就要按刷写流程文档来。

有一点要记住：10 03回复“50 03”并不意味着后面一定能执行27服务。这里还受ECU内部的子状态、应用状态、安全状态等影响。有些ECU在10 03之后还需要等待一段时间才能接受27，时间很短，但自动化测试里如果不加延时，可能在ECU还没完成会话切换时就发了27，结果得到0x22。

4.2 会话、重启、超时之后，解锁状态去哪儿了

安全访问的解锁状态通常不是永久有效的。这里说的“永久有效”，不是指点火周期或整车运行时长，而是指ECU内部诊断状态保持不变的时间范围。

最常见的情况是：ECU保持在扩展会话中，安全访问解锁状态可以持续存在，但一旦出现以下三种情况，锁会重新闭合：

第一种，ECU执行了会话切换。比如从扩展会话切回默认会话，或者从扩展会话切到编程会话，解锁状态一般会被清除。

第二种，ECU发生了复位或者下电。哪怕只是诊断仪触发了“11 01 ECU复位”，安全访问状态也会被清除。下一次要写参数，必须重新走一遍27服务。

第三种，S3Server超时。ECU会监视诊断仪的活动，如果在设定时间内没有收到任何诊断请求，它会自动跳回默认会话，附带结果就是安全访问状态也不再有效。S3Server的默认值一般是5秒，不同ECU可以配置成更长或更短。为了不让会话超时，诊断仪需要周期性地发送3E 00，也就是TesterPresent，来告诉ECU“我还活着”。

所以，当自动化测试脚本执行一串很长的写操作时，最怕的不是密钥错误，而是写到一半会话超时复位。然后脚本还继续拿旧的解锁身份去执行写服务，结果收到“7F 2E 33”或者“7F 31 33”。这种问题在日志里看起来像权限错误，实际根因是会话超时把安全状态清掉了。

4.3 3E保活与安全访问的真实关系

3E服务（TesterPresent）是UDS里用来保活的服务，请求报文通常是“3E 00”。很多人误以为发了3E就能保持解锁状态。不能说这个理解完全错，但更准确地说：3E保持的是诊断会话，而安全访问状态能否继续保持，主要取决于ECU会不会因为会话超时退出当前非默认会话，从而连带清除访问权限。

可以这样理解：假设安全访问状态是一张门禁卡的有效期，3E保活维持的是“会议不散场”。只要会议不散场，门禁卡就一直有效；但如果你长时间不刷卡，会议室会关闭，门禁卡自然也就刷不开了。也就是说，3E保活是维持安全状态的必要条件，但不是充分条件。ECU完全可以在会话保持有效的情况下，因为另外一套独立的安全访问超时策略而主动清除解锁状态。

在写自动化脚本时，我一般会在每两步关键操作之间周期性地发送3E 00，间隔可以设为2秒左右，低于S3Server的5秒默认值。如果ECU的S3Server更短，那么间隔就要相应缩小。还有一些更严格的ECU，会在安全访问解锁后规定一个最大允许时间，比如30秒内如果没有执行受保护的服务，就强制重新锁定。这种策略从信息安全角度说合理，但从测试角度看很容易被忽略。所以，不要以为“已经解锁了就一定能写数据”，还是要在执行受保护服务之前检查ECU是否仍然处于解锁状态，或者干脆采取“每次写操作前都重新解锁”的稳妥策略。

4.4 刷写场景里的典型时序记忆

刷写是UDS协议里最典型的“流程性操作”，也是27服务出现频率最高的场景。刷写通常不是只做一次安全访问，而是会在几个关键节点分别做。

我见过很多ECU的刷写时序是：

text复制10 02 进入编程会话
27 05 请求刷写级种子
27 06 发送刷写级密钥
34 00 请求下载
36/37 传输数据
31 01 02 03 检查编程完整性并退出

在这个过程里，如果在34之前没有完成27服务，ECU往往会直接拒绝下载请求，回复“7F 34 33”。所以，刷写脚本的健壮性判断，不能只在最后看是否刷写成功，而是要在每个节点检查正响应，尤其是27服务返回的NRC。只要有一个节点失败，立即停止整个流程，不要硬着头皮继续发数据，否则轻则刷写失败，重则可能导致ECU进入异常状态。

5. 实测记录：一次27服务返回0x7F 27 37的复盘

5.1 现场报文特征

前两个月，测试台架上报了一个很典型的问题：自动化脚本在执行刷写前解锁时，第一次运行能成功，第二次、第三次连续运行后，就开始稳定复现“7F 27 37”。测试工程师把报文抓出来，看到的序列大概是这样：

text复制发送: 10 03
接收: 50 03
发送: 27 05
接收: 67 05 32 19 A0 4E
发送: 27 06 FF 8B 21 0B
接收: 7F 27 37

问题在于，脚本里用的密钥算法是从上一个项目“继承”过来的，理论上应该没问题，因为第一次运行时成功过。但这次连续跑第二遍时，没有等待足够时间就再次请求种子并发送密钥，ECU判定“延迟时间未到”，直接回了0x37。

这种问题的根因往往不是密钥算错，而是ECU在上一次解锁失败、或上一次上电周期结束之后，内部维护了一个防护定时器。只要定时器没有走完，即使密钥正确，ECU也不接受新的安全访问请求。

5.2 为什么提示“延迟时间未到”

0x37这个响应码的核心逻辑是“安全访问请求太频繁”。设计这个机制的目的，是防止攻击者通过反复尝试密钥来暴力破解安全访问体系。ECU侧常见的实现方式有两类：

一类是单次延迟。每次发送错误密钥后，启动一个固定延时，比如10秒。在延时期间，即使请求种子也会被拒绝，或者种子请求本身可以成功，但发送密钥会被打回0x37。

另一类是递增延迟。第一次失败后等5秒，第二次失败后等20秒，第三次失败后等1分钟。这种策略更加严格，对自动化脚本的干扰也更大。

在我们的实测现场里，问题出在自动化脚本套用了上一台ECU的逻辑。上一台ECU在解锁失败两次后才会触发0x37，而当前这台ECU只要一次失败就会进入10秒锁定。脚本在没有增加等待的前提下连续重试，自然就一直撞在0x37上。

5.3 把时序调整成可复现的稳定流程

既然找到了原因，解决办法就很直接：在安全访问失败后，加入“等待+重置”机制。通用的处理流程我建议这样写：

第一步，收到0x35密钥无效时，先停下脚步，检查密钥算法的种子字节序、密钥长度和算法版本。如果算法确认正确，那可能是上一次会话残留状态导致的问题，可以等待3到5秒后重新请求一次种子。

第二步，收到0x37延迟未到时，不要立刻重试，而应该读取诊断规范里的延迟时间参数，按参数设置等待。如果规范里没有写，至少先等10秒。

第三步，收到0x36超过尝试次数时，放弃在当前上电周期内继续尝试。最可靠的做法是让ECU重新上电或执行ECU复位，把计数器和定时器全部清零。

注意，执行ECU复位本身也可能带来额外的副作用，比如让ECU重新进默认会话、重新进行初始化、丢掉非易失性写入数据。所以，在自动化测试流程里，一般不建议为了重置安全访问计数器而频繁复位ECU，而是应该在测试用例设计阶段就把每次安全访问之间的间隔留足。

还有一个更省事的经验：把“进入扩展会话 + 安全访问解锁”封装成一个独立步骤，并在这个步骤前后加入明显的状态打印。一旦遇到0x36或0x37，就明确提示“等待后重试”，让执行测试的人不会误判成密钥错误。

5.4 其他常见错误：种子缓存、会话过期、错误等级

顺着这次故障，我顺便把27服务最常见的三类低级错误一起梳理一遍。

第一类是种子缓存问题。有些工具为了提高速度，会把上次收到的种子和算好的密钥记录下来，下次直接发送缓存内容。这在ECU重启、会话切换后基本无效，因为ECU内部的种子时效性已经过了。因此，工具设计里应该把“缓存安全访问结果”的功能默认关闭，除非诊断规范明确允许在同一个会话内复用解锁状态。

第二类是会话过期问题。解锁之后长时间没有和ECU通信，S3Server超时导致会话退回默认，此时再发送原本受保护的2E、31、34服务，就会收到0x33。测试日志里需要把3E保活间隔和对端超时参数联动起来看，不要只盯着一帧NRC。

第三类是错误等级问题。安全等级不是只有一个档位，有些ECU在扩展会话下解锁了等级1，但写配置要求等级2，这时发送2E同样会被打回0x33。所以认真阅读诊断规范里“每个服务要求的安全等级”一列，比在代码里反复试错更高效。

6. 落地到代码和工具链的几条规定

6.1 谁允许发27服务：物理寻址的约束

在实际的总线通信里，UDS请求分为物理寻址和功能寻址两种。功能寻址通常用于一对多广播，比如用19服务同时读取多个ECU的DTC，或者用10服务让多个ECU同时进入某种状态。但27服务一般不支持功能寻址。

原因很简单：安全访问请求里带着种子和密钥，如果广播给总线上所有ECU，一方面会泄露敏感信息，另一方面不同ECU的种子长度和密钥算法都不一致，功能寻址也无法得到统一处理。因此，绝大多数ECU在收到功能寻址的27请求时，要么不响应，要么返回否定响应码0x7F 27 12之类的错误。

在编写测试工具时，要明确诊断请求的寻址方式。同一个CAN ID既可能被用于物理寻址，也可能被用于功能寻址，发送27服务前，一定要确保工具选择了正确的目标地址类型。很多测试脚本默认把请求发到功能寻址，结果普通服务正常、唯独27服务没有响应，排查了半天才发现是寻址类型选错了。

6.2 种子和密钥日志的隐私问题

诊断过程中抓到的报文，即使不打印密钥算法本身，也可能包含敏感信息。种子里包含了随机数或时间相关数据，密钥则是通过算法计算出来的结果。在开发测试阶段，把完整报文打印到控制台还问题不大；但如果工具链被交付到产线或售后，就必须考虑日志脱敏和权限管理。

我见过一些售后诊断软件，在日志文件里把27报文的种子和密钥全部明文记录下来。这样一旦日志文件外泄，即使没有算法，攻击者手里也会有大量“种子—密钥”样本，可能加大逆向风险。因此，工具链在记录诊断日志时，对27服务建议只记录“子功能号+响应状态+NRC”，不要把种子和密钥原样写入日志。如果确实需要记录，也应该加访问权限控制，并设置过期销毁机制。

6.3 把解锁做成独立模块，而不是贴在测试脚本里

很多测试工程师习惯把解锁流程直接写在自动化脚本里，序列大概是“发送10 03，延时，发送27 05，解析种子，调用算法DLL，发送27 06”。这个写法本身没错，但问题是它把安全访问与具体业务逻辑耦合在了一起。一旦安全等级变化、算法版本升级、子功能号调整，就要满工程地搜索27相关的代码去改。

更推荐的做法是做一个独立的“SecurityAccessClient”模块，对外提供几个稳定接口：

text复制SetDiagnosticSession(session)
Unlock(securityLevel)
Lock()
GetSecurityState()

内部封装好状态管理、定时等待、NRC解析和重试策略。业务脚本只需要调用Unlock(0x05)就能完成解锁，不用关心底层报文的拼包和时序。这样一来，测试脚本更清晰，也减少跨项目复用时改代码的工作量。

6.4 配合19服务、2E服务、31服务时的典型调用顺序

最后把27服务跟其他服务放在一条完整的链路里看。实际项目里，27服务很少单独出现，它总是给后面的服务做铺垫。

比如一个常见的生产下线场景，要写入车辆配置，并按VIN码生成DTC后确认状态。典型顺序是：

19服务先查询是否有历史故障码，如果有，用14服务清除；接着写配置前，用27服务解锁；再使用2E服务写入VIN或配置字；最后用31服务执行一次“保存并重启”例程。

另一个场景是标定工程师经常遇到的：进扩展会话，读取当前标定值（22服务），解锁（27服务），写入一组新标定值（2E服务），调用例程让标定生效（31服务）。整个过程里，读取阶段不需要解锁，但写标定值之前一定要完成安全访问，否则2E会返回0x33。

我在设计诊断功能测试用例时，一般会画一张“前置条件—动作—预期结果”的表格。前置条件里明确写上：诊断会话、是否解锁、解锁等级、是否物理寻址。这样无论谁执行用例，都不会漏掉27服务这一步。

7. 最后写几条贴在我工位上的速记

做安全访问相关的诊断开发时间久了，反而觉得最重要的不是密钥算法本身，而是流程、状态、时序和通信边界这些容易被忽略的细节。我把平时最容易出问题的地方浓缩成这几条，贴在工位上：

第一，27服务前面的会话状态一定要确认。不要默认ECU已经处于扩展会话，要在代码里主动切换并确认正响应。

第二，子功能靠奇偶记忆：奇数请求种子，偶数发送密钥。等级编号以诊断规范为准，不要凭经验跨项目套用。

第三，看到7F 27 35先查算法和拼包；看到7F 27 36立刻停止重试并考虑针对当前上电周期的复位策略；看到7F 27 37先数时间，很多情况是等待不够。

第四，安全访问解锁不是永久授权，ECU复位、会话切换、S3Server超时都可能让锁重新闭合。需要长时间执行写操作时，加入3E保活并在操作前重新确认解锁状态。

第五，27服务一般不要用功能寻址，日志里不要记录明文密钥。

这些内容看起来琐碎，但每一条都来自实际排故过程中踩过的坑。跟同事讨论问题时，我越来越觉得，UDS诊断中信息安全的关键不在某个响应码，而在于对整个通信时序和状态机的理解。把27服务放进整车诊断的大状态机里去看，很多看似神秘的NRC其实都能顺藤摸瓜找到根因。这份速记笔记希望能帮正在做uds诊断开发或者正在调试SecurityAccess的同行省下一些排查时间。