UDS_SecurityAccess(0x27)服务

一、服务功能：

根据ISO14119-1标准中所述，诊断服务27应用场合主要是用于Server数据上传或者下载，重要信息传递，功能安全等实施的过程中。该服务的目的是为那些限制访问，以及和排放、安全相关的一些服务和数据提供一些访问权限来保护数据。

执行步骤：

具体过程可分为以下四个阶段：

  ①Client向Server请求种子

  ②Server向Client发送随机种子；

  ③Client基于接收到来自Server的随机种子计算出对应的Key并发送给到Server；

  ④Server接受来自Client算出来的Key并与内部算出的Key比较，如果一致则解锁成功，否则解锁不成功；

请求Seed的子功能发送的参数一定是奇数，而应答发送Seed的子功能参数则是这个奇数+1。只有当前请求的Seed所在安全等级的功能才可以被激活，其他安全等级的会被上锁。（这里所说的参数不是指的是sub-function之后带有的参数，而是指sub-function, 且sub-function(Request Seed) + 1 = sub-function(Send Key)。

二、应用场景：

一般而言，对于27诊断服务，主要应用场景为以下场合：

①：在针对Server重新编程时，需要首先通过27安全解锁才能够进行后续的重编程操作，否则将对Server造成极大的安全风险；

②：在产线写入较为重要的版本或者标定等信息过程中，则首先需要使用27服务才能够使用写操作的诊断指令，如2E服务；

③：一般而言，如果需要往Flash中写入相关数据时都需要优先执行27安全解锁之后才能够进行安全写入；

④：执行十分重要的31 Routine时，也需要优先执行27安全解锁之后才能够执行对应的routine；

简而言之，需要安全访问的应用：

2E服务、2D服务（WriteMemoryByAddress）、2F服务(InputOutputContorIByIdentifier)、31服务。

三、服务请求：

请求Seed格式：

SecurityAccess Request SID：27为Server ID，表示安全访问请求ID

SubFunction：请求Seed子服务，必须为奇数，值可为：01，03，05，07 to 7D

securityAccessDataRecord：Client发送给到Server的标识信息，可选，一般不用；值可为00-FF

发送Key格式：

SecurityAccess Request SID：27为Server ID，表示安全访问请求ID

SubFunction：发送Key子服务，必须为偶数，值可为：02，04，06，08 to 7E

securityAccessDataRecord：Client向Server发送的具体Key值

Note：虽然27服务也支持抑制正响应，但是由于27服务需要通过正响应或者负响应来判断是否成功解锁，所以一般情况下针对27服务我们一般不使能抑制正响应位。

subfunction取值定义说明：

四、服务响应：

正响应格式：

Response ID：该参数固定为SID+0x40 = 0x67；

SubFunction：该参数为request seed(如01)或者Send Key(02)的取值;

securitySeed：该参数仅针对subfunction为Request Seed时才会回复该参数，其他情况下，Server仅会回复前两个字节(response SID + SubFunction)，其取值范围只能为0x00-0x7F；

五、支持的NRC：

六、问题学习：

1、27服务的Seed，何时可以返回全0？

答：如果Server已经处于解锁状态（Unlock）,在此会话下，再次收到Client的种子请求，可以返回0，以此告知上位机，当前会话已经解锁。

2、非默认会话再次跳转相同非默认会话，需要重新解锁吗？

答：需要重新安全解锁，即：重新执行0x27服务。