用于电子控制单元的软部件认证的制作方法
未命名
09-29
阅读:81
评论:0
1.本公开涉及认证软部件更新,例如但不必限于认证用于包括在车辆的电子控制单元(ecu)上的软部件的更新。
背景技术:
2.电子控制单元(ecu)可以被认为是计算机、微控制器或其他处理元件,其被配置为提供或以其他方式支持一个或多个操作、功能、过程等,诸如通过向附属系统输出相应的信号、数据、控制等。ecu通常是独立的装置,其旨在定期操作附属系统,例如重复地分析信息、测量、值、输入等,以便实现对附属系统的相应输出和控制,并且在一些情况下,例如当不直接控制附属系统时,向另一ecu或其他实体提供信息等。ecu的强调部件可以变化;然而,许多通常被认为包括处理器以根据存储在所包括的存储器上的执行非暂时性指令来执行功能,即,指令表示用于促进期望的操作、功能等的软件或其他逻辑。
3.当在其中随ecu等执行的操作旨在在其整个生命周期中相对一致或类似的应用中采用ecu等时, ecu等可以被视为受约束或固定类型的系统。这样的ecu可以部署在主机装置内以便具有有限的可访问性或者部署在通常远离用户交互的位置,并且因此可能缺少用户接口或人机接口(hmi)。这样的ecu相反可以依赖于有线或无线连接,诸如通过网络或通过另一通信,以促进与其他ecu、装置、传感器、附属系统等的交互。作为示例,当用于例如汽车的车辆时,各种ecu可以用作发动机控制模块(ecm)、远程信息处理单元(tu)、动力系控制模块(pcm)、变速器控制模块(tcm)、制动控制模块(bcm)、中央控制模块(ccm)、中央定时模块(ctm)、乘客门模块(pdm)、系统控制模块(scm)、气囊控制模块(acm)、电池管理系统(bms)、通用电子模块(gem)、车身控制模块(bcm)、悬架控制模块(scm)等。
4.ecu可以周期性地要求更新,在提到的汽车类型ecu的情况下,更新可以与设计更新、校准改变、新的或改变的功能以及通常与改变软件、代码、固件、数据集、文件等相关联的其他改变相关联。这些特征或配置可以被称为软部件,因为软部件通常被理解为包含这样的特征。因此,一些更新可以涉及改变代码或软件以便改变功能,而一些其他更新可以涉及调整校准表、添加用于查找功能的数据、或者修订依赖于但不一定与改变功能相关的信息值。ecu彼此通信以及与其他实体通信以更新软部件或以其他方式进行操作改变的装置和方法可以根据实现方式并且通常根据与主机装置相关联的标准和协议而变化。
5.至少在一些汽车的情况下,统一诊断服务(uds)是一种常用的诊断通信协议,以便于更新汽车电子器件,如ecu。国际标准化组织维护了名为iso 14229-1公路车辆统一诊断服务(uds)的uds标准,其全部内容通过引用并入本文。uds的一个有价值的方面是旨在防止或阻止不希望的行动者在没有适当认证的情况下进行更新的服务。与相应的安全访问相关联的服务标识符(sid)通常参考请求sid 0x27和响应sid 0x67,其涉及基于种子的请求-响应策略。该策略实现了认证过程,由此ecu生成种子并将其发送到编程工具,然后编程工具响应地使用该种子来生成密钥并将其发送回ecu。然后,ecu根据响应密钥(即,来自编程工具的密钥)是否与ecu的密钥匹配来验证编程工具以对ecu进行更新。uds至少以这种方式有
效地认证行动者对ecu的访问,并且由此得到进行更新的许可,只要行动者能够提供匹配密钥。
技术实现要素:
6.本文公开了一种认证对软部件的更新的认证方法和系统,例如,通过要求试图更新ecu或其他控制器的软部件的编程工具或其他实体不仅能够访问软部件签名系统或软部件签名密钥(即,ecu信任的密钥),而且还执行附加认证,目的在于确保从可信机构或服务提供的软部件更新在ecu处实现时不被改变。所构想的认证能力帮助确保诸如原始装置制造商(oem)的经授权的软部件销售商能够在更新软部件时保护对ecu的访问,以使得更新被限于经授权的软部件,并使得减少了不希望的行动者作出改变或以其他方式干预更新的机会。
7.公开了一种认证电子控制单元(ecu)的软部件更新的方法。该方法包括:确定包含在从编程工具发送到ecu的发送密钥请求内的发送密钥信息,并从发送密钥信息中识别是否要根据第一类型认证或第二类型认证来认证软部件更新。ecu可以被配置为执行第一和第二类型两者。第一类型允许ecu响应于完成解锁密钥认证而更新。第二类型允许ecu响应于除了完成解锁密钥认证之外还认证为软部件创建的消息摘要而进行更新。
8.该方法可以包括:要求ecu执行质询认证(challenge authentication)以便确定是根据第一类型还是第二类型来认证更新,例如,当质询认证不成功时根据第一时间执行认证,并且当成功时根据第二类型执行认证。
9.该方法可以包括:当ecu生成质询消息认证码(mac)和响应mac并将它们两者与发送密钥信息内包括的相应的质询和响应mac进行匹配时,确定质询认证成功。
10.该方法可以包括:要求ecu通过用解锁密钥来签名质询来生成质询mac,并且可选地,在ecu通过将ecu标识符(id)与随机数级联来生成种子之后在将子函数与种子级联之前设置子函数的最高有效位(most significant bit)来生成质询。ecu可以通过利用会话密钥对第一常数签名来生成响应mac。
11.该方法可以包括:将利用ecu生成的质询mac的不多于x个最高有效位与包括在发送密钥信息内的质询mac匹配,以及将利用ecu生成的响应mac的不多于y个最高有效位与包括在发送密钥信息内的响应mac匹配,例如,x可以是16,y可以是12,使得质询mac的16个最高有效位被匹配,并且响应mac的12个最高有效位被匹配。
12.该方法可以包括:在质询认证之后并且在更新软部件之前,要求ecu完成数据认证和模块认证中的每个。
13.该方法可以包括:当ecu生成数据mac并将其与附加认证请求内包括的对应数据mac进行匹配时,确定要完成数据认证,该附加认证请求在质询认证之后从编程工具被发送到ecu。
14.该方法可以包括:要求ecu通过利用共享秘密对消息摘要签名来生成数据mac。消息摘要可以包括在发送密钥信息内,并且在此之前通过根据算法处理软部件而生成。
15.因此,该方法可以包括:当ecu验证用编程工具识别的模块id与包括在其上的模块id匹配时,确定完成模块认证,并且可选地在更新软部件之前验证软部件的签名,该签名包括在发送密钥信息中。
16.该方法可以包括:解锁密钥认证要求ecu在其上存储与包括在发送密钥信息内的解锁密钥匹配的解锁密钥。
17.公开了一种认证车辆的电子控制单元(ecu)的软部件更新的方法。该方法可以根据从编程工具发送到ecu的信息,包括响应于ecu验证解锁密钥以及软部件的消息摘要而认证软部件更新,由此解锁密钥和消息摘要被包括在信息内,并且消息摘要从后台提供给编程工具以认证软部件更新。
18.该方法可以包括:当与消息摘要相关联并且包括在信息内的消息认证码(mac)与ecu生成的相应mac匹配时,ecu确定消息摘要得到验证。
19.公开了一种用于向车辆的电子控制单元(ecu)认证软部件的系统。该系统可以包括后台,其被配置用于生成用于软部件的消息摘要和签名,例如后台可以响应于验证对软部件的更新的真实性而生成消息摘要和签名。该系统可以包括编程工具,该编程工具被配置用于将消息摘要和签名与提供给ecu的信息包括在一起,ecu响应于该信息确定是否验证更新。
20.编程工具可以包括用于信息内的消息摘要的消息认证码(mac)和解锁密钥,由此当mac、签名和解锁密钥与由ecu本地确定的mac、签名和解锁密钥匹配时,ecu响应地确定更新得到验证。
21.本发明还包括如下方案:方案1. 一种认证电子控制单元(ecu)的软部件更新的方法,包括:确定被包括在从编程工具发送到所述ecu的发送密钥请求内的发送密钥信息;以及从所述发送密钥信息识别所述软部件更新是要根据第一类型的认证还是第二类型的认证来认证,所述ecu被配置为执行所述第一类型和所述第二类型两者,所述第一类型允许所述ecu响应于完成解锁密钥认证而更新,所述第二类型允许所述ecu响应于除了完成所述解锁密钥认证之外还认证为所述软部件创建的消息摘要而更新。
22.方案2. 根据方案1所述的方法,还包括:要求所述ecu执行质询认证以便确定是根据所述第一类型还是所述第二类型来认证所述更新,当所述质询认证不成功时,要求所述ecu根据所述第一类型进行认证,并且当所述质询认证成功时,要求所述ecu根据所述第二类型进行认证。
23.方案3. 根据方案2所述的方法,还包括:当所述ecu生成质询消息认证码(mac)和响应mac并且将所述质询消息认证码和所述响应mac两者匹配到包括在所述发送密钥信息内的对应的质询和响应mac时,确定所述质询认证成功。
24.方案4. 根据方案3所述的方法,还包括:要求所述ecu通过利用解锁密钥对质询进行签名来生成所述质询mac。
25.方案5. 根据方案4所述的方法,还包括:通过在将子函数与种子级联之前设置所述子函数的最高有效位来要求所述ecu生成所述质询,所述ecu通过将ecu标识符(id)与随机数级联来生成所述种子。
26.方案6. 根据方案5所述的方法,还包括:要求所述ecu通过利用会话密钥对第一常数签名来生成所述响应mac。
27.方案7. 根据方案6所述的方法,还包括:将利用所述ecu生成的质询mac的不多于x
个最高有效位与包括在所述发送密钥信息内的质询mac进行匹配。
28.方案8. 根据方案7所述的方法,还包括:将利用所述ecu生成的所述响应mac的不多于y个最高有效位与包括在所述发送密钥信息内的所述响应mac进行匹配。
29.方案9. 根据方案8所述的方法,还包括:选择所述x为16和所述y为12,使得所述质询mac的16个最高有效位匹配,并且所述响应mac的12个最高有效位匹配。
30.方案10. 根据方案6所述的方法,还包括:在所述质询认证之后在更新所述软部件之前,要求所述ecu完成数据认证和模块认证中的每一者。
31.方案11. 根据方案10所述的方法,还包括:当所述ecu生成数据mac并将所述数据mac与包括在附加认证请求内的对应数据mac进行匹配时,确定完成所述数据认证,在所述质询认证之后,所述附加认证请求从编程工具被发送到所述ecu。
32.方案12. 根据方案11所述的方法,还包括:要求所述ecu通过利用共享秘密对所述消息摘要进行签名来生成所述数据mac。
33.方案13. 根据方案12的方法,还包括:消息摘要被包括在所述发送密钥信息内,并且在此之前通过根据算法处理所述软部件而生成。
34.方案14. 根据方案13所述的方法,还包括:当所述ecu验证利用所述编程工具识别的模块id与包括在其上的模块id匹配时,确定完成所述模块认证。
35.方案15. 根据方案14所述的方法,还包括:要求所述ecu在更新所述软部件之前验证所述软部件的签名,所述签名与所述发送密钥信息包括在一起。
36.方案16. 根据方案2所述的方法,还包括:所述解锁密钥认证要求所述ecu在其上存储有与包括在所述发送密钥信息内的解锁密钥匹配的解锁密钥。
37.方案17. 一种认证车辆的电子控制单元(ecu)的软部件更新的方法,所述方法包括:根据从编程工具发送到所述ecu的信息,响应于所述ecu验证解锁密钥以及所述软部件的消息摘要,认证所述软部件更新,所述解锁密钥和所述消息摘要被包括在所述信息内,所述消息摘要从后台被提供给所述编程工具以认证所述软部件更新。
38.方案18. 根据方案17所述的方法,还包括:当与所述消息摘要相关联并且包括在所述信息内的消息认证码(mac)与由所述ecu生成的对应mac匹配时,所述ecu确定所述消息摘要得到验证。
39.方案19. 一种用于向车辆的电子控制单元(ecu)认证软部件的系统,所述系统包括:后台,其被配置用于生成用于所述软部件的消息摘要和签名,所述后台响应于验证对所述软部件的更新的真实性而生成所述消息摘要和所述签名;以及编程工具,所述编程工具被配置用于将所述消息摘要和所述签名与提供给所述ecu的信息包括在一起,所述ecu响应于所述信息来确定是否验证所述更新。
40.方案20. 根据方案19所述的系统,其中,所述编程工具包括用于所述信息内的所述消息摘要的消息认证码(mac)和解锁密钥,当所述mac、所述签名和所述解锁密钥与由所述ecu确定的mac、签名和解锁密钥匹配时,所述ecu响应性地确定所述更新得到验证。
41.本公开的上述特征和优点以及其他特征和伴随的优点从在结合附图和所附权利要求书时的对用于实施本公开的说明性示例和模式的以下详细描述将是显而易见的。此
外,本公开明确地包括上文和下文呈现的元件和特征的组合和子组合。
附图说明
42.附图被并入本技术文件中并构成本技术文件的一部分,附图示出了本公开的实施方式,并且与说明书一起用于解释本公开的原理。
43.图1示出了根据本公开的一个非限制性方面的用于认证软部件更新的系统。
44.图2a-图2b示意性地示出了与根据本公开的一个非限制性方面的用于认证软部件更新的方法相关联的图。
45.附图不一定按比例绘制,并且可以呈现如本文所公开的本公开的各种特征的稍微简化的表示,包括例如特定尺寸、定向、位置和形状。与这些特征相关的细节将部分地由特定的预期应用和使用环境来确定。
具体实施方式
46.本公开可以以许多不同的形式来实施。代表性示例在各个附图中示出并且在本文中详细描述为所公开的原理的非限制性表示。为此,在摘要、背景技术、发明内容和具体实施方式部分中描述的但未在所附权利要求中明确阐述的元素和限制不应通过暗示、推断或其他方式单独或共同地结合到权利要求中。此外,除非特别地放弃,单数的使用包括复数,反之亦然,术语“和”和“或”应该既是连接性的又是分离性的,“任何”和“全部”应该都表示“任何以及全部”,并且词语“包括”、“包含”、“含有”、“具有”等应该表示“包括而不限于”。
47.诸如“大约”、“几乎”、“大致”、“大体”、“大约/近似”等的近似词可以在“处于、接近或几乎处于”或“在
……
的0-5%内”或“在可接受的制造公差内”或其逻辑组合的意义上在本文中使用。同样如本文所使用的,“被配置成”执行指定功能的部件能够在不改变的情况下执行指定功能,而不是仅具有在进一步修改之后执行指定功能的潜力。换句话说,当明确地配置成执行指定功能时,所述硬件被具体地选择、创建、实现、利用、编程和/或设计,以用于执行指定功能的目的。为了便于描述,本文中可使用诸如“内”、“外”、“下方”、“下面”、“上方”、“上面”、“上”等空间相对术语以描述一个元件或特征与附图中所示的另一元件或特征的关系。空间相对术语可以旨在包括除了附图中描绘的定向之外的装置或系统在使用或操作中的不同定向。
48.现在参考附图,其中在所有的几个视图中相同的附图标记表示相同的特征,图1示出了根据本公开的一个非限制性方面的用于认证软部件更新的系统10。出于示例性目的,主要关于促进对汽车上包括的电子控制单元(ecu) 12的更新来描述该系统,因为本公开完全考虑了其在保护对ecu之外的装置的更新以及对非汽车装置的更新中的使用和应用。系统10主要根据编程工具14、后台16和ecu 12之间的交互来操作,由此每一者协作以便于根据本文考虑的过程和方法来认证软部件更新。虽然未详细示出,但是每个可以包括被配置用于执行在所包括的存储器上的非暂时性指令以促进本文描述的各种操作、功能和活动的处理器,并且同样地,每个还可以包括实现所述各种操作、功能和活动所需的合适的接口、连接、通信能力等。
49.后台16可以被认为是可信机构,例如在原始装置制造商(oem)的控制或指导下的可信机构,其任务是验证用于更新的软部件。需要更新的软部件可从内部和/或外部源20提
供,并被递送到软部件发布系统22以供验证。验证可以包括由管理员决定软部件是否适合于更新,这可选地可以包括识别预期用于相应更新的ecu以及协调安装所需的模块id和其他信息。软部件发布系统22可以包括能够存储软部件并将其与ecu标识符(id)和模块id交叉引用的数据库,使得发布系统22可以有效地维护授权给每个ecu 12的软部件的最新版本。每个软部件可以包括ecu id、模块id、部件编号等或以其他方式与之相关联,以协调其与文件、数据集或具有形成软部件的软件、代码、编程等的其他内容的使用,即,要编程到ecu 12中的信息可以包含在能够被传送到ecu 12并由ecu 12作用的对应文件或结构内,以便于在实现本文所设想的认证之后在其上进行安装。
50.后台16被示为包括与软部件签名系统24和ecu解锁安全服务器26相关联的安全特征。签名系统24和安全服务器26可以协作以便于保护用于认证更新的软部件的认证措施。安全措施可以存储用于实现各种密码处理和操纵的信息,包括用于利用密钥、散列算法、媒体认证码(mac)、共享秘密等的能力。发布系统22可以用于生成每个软部件的消息摘要,然后将其提供给安全服务器26,以根据每个ecu 12已知的、旨在接收的共享秘密生成验证数据(例如mac),例如通过将消息摘要和相关联的软部件编号以及模块id与共享秘密级联并随后对其进行签名。这确保安全服务器26向ecu 12提供软部件的附加的认证数据,该软部件已经被授权在发布系统22中进行官方发布。这样,即使闯入者获得对签名系统24或签名系统24所使用的软部件签名密钥的访问,ecu 12仍然可以检测到所提供的软部件更新不是可信的。安全服务器26可负责追踪解锁密钥、共享秘密等,且出于示例性目的而示为与签名系统24分离,仅为了突出本公开的一个方面,借此与每个ecu 12相关联的密钥、秘密等可与软部件签名系统24分离地维持。此分支(bifurcation)可有助于使软部件发布系统22能够与现有ecu安全系统26集成,使得本公开可并入到现有控制结构中。安全服务器26可与发布系统22和/或签名系统24交互以向其提供密钥、共享秘密和其他信息,以用于生成消息摘要和其他数据集的目的。
51.编程工具14可以与安全服务器26和/或后台16的其他元件交互,以便于用ecu 12验证软部件。编程工具14可以对应于具有足以与ecu 12交互的能力的装置。例如,编程工具14可以对应于能够连接到网络或直接连接到ecu 12的独立测试器,例如,在车辆的情况下,测试器可以连接到与ecu 12通信的车辆网络,和/或测试器可以直接插入ecu 12的插座或接口。编程工具14(可选地,不是独立的测试器)可以被包括在具有需要软部件更新的ecu的装置的模块或另一ecu内,例如,一个ecu可以作为另一ecu的编程工具。编程工具14还可以远离具有ecu 12的装置定位,以便于无线或空中(ota)更新。编程工具14可以包括用户接口或人机接口(hmi),以便于在需要时与管理员交互,以便输入与便于更新的用户相关方面相关联的信息和命令。
52.编程工具14可以是ecu 12或装置的通用物品或非特定物品,只要它可能需要信息、文件和其他数据被加载到其上。可以包括实用工具文件28以向编程工具14提供期望的或特定的信息,例如,实用工具文件28可以包括与软部件相关联的软件、校准表、编码等的副本(即,要提供给ecu 12以用于更新的数据集),以及便于本文所设想的认证的其他信息。实用工具文件28可以存储在编程工具14上,或者以其他方式提供给它,例如从后台16通过有线或无线通信提供。本公开的一个方面设想,当车辆技术人员或所有者在装置上工作或以其他方式处在他们可能需要与编程工具14交互的这样的环境中、同时编程工具在范围之
外或不与后台16通信时,编程工具14被车辆技术人员或所有者使用。这可以通过提前向编程工具14加载实用工具文件28来实现,从而此后可以将其带到具有ecu 12的装置。当然,可能不需要具有单独的编程工具14或预加载编程工具14,特别是随着无线通信范围的增加,从而在本文描述的一些或所有交互可以通过有线或无线信号直接在后台16和ecu 12之间发生。
53.图2a-图2b示意性地示出了与根据本公开的一个非限制性方面的用于认证软部件更新的方法相关联的图30。相对于与uds安全访问相关联的至少一些消息传递和交互,主要出于示例性目的描述了与后台16、编程工具14和ecu 12相关联的方法和相应的基础设施。特别地,出于非限制性目的关于uds和请求sid 0x27和响应sid 0x67描述了各种消息、响应、请求、过程和序列,因为本公开完全考虑了其与其他协议和标准的使用和应用,并且主要关于消息传送、通信等的其他序列和类型来描述。因此,uds仅作为通常使用的一种类型的安全协议的参考框架而呈现,所述安全协议可受益于本文所描述的额外认证措施且可与其协作使用。
54.根据编程工具14向ecu 12发送部件编号请求36,并且ecu 12作为响应发送回部件编号响应38,部件编号认证34被示出为发生。部件编号响应38可以包括16位ecu id以及存储在ecu 12上的软部件编号和模块id的列表,即,在其上运行的每个软部件的列表。可以为软部件的每个版本分配新的部件编号,使得软部件编号随每个版本而改变,并且模块id可以保持不变。模块id的一致性可以有利于帮助向ecu 12识别与其上包括的软部件的存储和使用相关联的存储器分区和其他信息。因此,部件编号响应38可以包括与相应模块id交叉引用的软部件编号的列表,例如以文件或查找表的形式。
55.编程工具14可以将从ecu 12提供的软部件编号与利用实用工具文件28识别的软部件进行比较,以识别ecu 12上需要更新的软部件。当新的软部件编号可用时,例如新版本,诸如当与其相关联的程序或代码改变时和/或当校准文件或其他信息要被添加或以其他方式与软件相关联时,可认为软部件需要更新。当软部件丢失或在ecu 12上不正确地操作时,也可以认为该软部件需要更新。软部件更新可以与软件、代码、支持文件或表、以及存储在ecu 12上的与其操作相关联的其他信息所期望的改变相对应。
56.响应于确定一个或多个软部件需要更新,编程工具14可以可选地以uds中描述的方式启动与ecu 12的安全访问,由此编程工具14发出0x27种子请求40。种子请求40可以提示ecu 12生成种子42,并且此后在响应44内将种子42发送到编程工具14。种子42可以由ecu 12将16位ecu id与ecu 12也可以生成的15位随机数级联在一起来生成。ecu id可以是ecu 12的唯一标识符,并且随机数可以是15位值,其用作旨在确保先前发行的种子不被重新使用的安全措施。如果值是未知的或者以足以阻止中继攻击的方式进行防护,则可以可选地使用值而不是随机数。
57.虽然它可以在接收软部件编号之前或不接收软部件编号的情况下被发起,但是质询认证46 (见图2b)可以在编程工具14接收种子42之后被执行。质询认证46可以被用于确定更新软部件所需的认证的类型。本公开考虑了所采用的多个认证阶段和过程,并且出于示例性的非限制性目的,主要描述了第一类型和第二类型的认证。下面更详细描述的第一类型认证可以对应于基于种子的请求-响应策略,由此响应于完成解锁密钥认证,即,接收在编程工具14或后台16从种子42得到的解锁密钥并且验证与由关联于签名系统24的软部
件签名密钥创建的有效数字签名相关联的软部件,ecu 12授权用于软部件更新的编程会话。第二类型的认证可以对应于更鲁棒的策略,其要求ecu 12完成除了验证解锁密钥和签名之外的附加认证,即,还要求编程工具14向ecu提供具有由签名系统24创建的有效消息摘要的软部件。
58.质询认证46可以包括编程工具通过将子函数与种子42级联来生成质询48。该子函数可以用于识别用于更新的安全许可或安全会话。例如,子函数可以以这种方式用于识别编程工具的权利,或者更具体地识别其用户,以对ecu 12进行某些更新。下面示出示例性质询48。
59.(subfunction:子函数,random number:随机数)不同级别的权利可用于指示编程工具14被允许进行的更新的类型,这可以取决于其用户,例如,工厂级别的权利可以使得能够对ecu 12进行比消费者级别的权利更多的改变。本公开的一个非限制性方面设想了经销商级别的权利,由此经销商的技术人员或技工可以能够对ecu 12进行更新,该更新比可以在ecu 12的工厂或制造位置进行的更新不那么重要,但是比可以由具有ecu 12的装置的消费者或所有者进行的更新更重要。
60.具有质询48和可选的需要更新的软部件编号的质询请求或消息52可以从编程工具14传送到后台16用于认证分析54。分析54可以包括后台16利用软部件编号来识别需要更新的软部件和相应的消息摘要和与其相关的模块id。分析54还可以使用子函数来确定编程工具14是否被授权进行某些更新,例如,后台16可以根据与子函数相关联的权利级别过滤或限制提供给编程工具14的消息摘要或其他更新信息,使得可以根据权利级别完全防止或限制一些更新。分析54还可包括确定更新软部件是否需要第一类型或第二类型的认证。后台16确定认证应该是第一类型还是第二类型的能力可以有利于使得能够选择性地确定其使用,例如根据ecu 12的能力、与编程工具14相关联的权利和/或根据相关联的软部件是否已经完成与软部件发布系统22相关联的验证过程。
61.分析过程54可包括:当需要第二类型的认证时将质询48内所包括的子函数的最高有效位设置为1;以及当需要第一类型的认证时将最高有效位保持为0。以这种方式设置最高有效位被认为是基于子函数的设计参数,该子函数通常在其开始处包括多个零,使得其从0到1的设置在利用子函数识别的安全级别没有影响的范围内实际上是无事件。虽然可以采用其他机制来指定是否应当根据第一或第二类型的认证来执行更新,但是以这种方式设置最高有效位可能足以指示ecu 12是否进行第一或第二类型的认证。分析过程54可以包括生成标记时间点或其他时间参考的第一计数器,该时间点或其他时间参考可以用于阻止与之相关联的信息的防重放使用,例如以确保在本文所预期的安全措施的生成和使用之间的定时关系。
62.分析过程54可以包括:在最高有效位被设置为1或保留在0之后,通过用与ecu 12相关联的解锁密钥(ecuuk)签名所述质询48,生成可以称为会话密钥的质询消息认证码(mac) 58,即,质询mac 58包括子函数,其中最高有效位根据认证类型被设置或保持不被设置。下面示出了示例性的质询mac 58。
63.(challenge:质询)分析过程54可以还包括:通过利用后台16和ecu 12已知的共享密钥签名附加认证数据来生成数据mac 60,该共享密钥可选地可以从解锁密钥导出。附加认证数据可以对应于软部件编号和/或模块id与相应消息摘要的级联。换句话说,消息摘要可以与在后台16处利用算法进行散列或指纹处理的软部件相对应,使得附加认证数据与每个软部件的消息摘要以及与其级联的附加信息相对应。下面示出了示例性的数据mac 60。
64.(shared secret:共享秘密,additional authentication data:附加认证数据)通过利用共享秘密签名第一计数器,可以单独地生成计数器mac 62。下面示出了示例性计数器mac 62。
65.(shared secret:共享秘密,first counter:第一计数器)当确定第二类型的认证时,可以在消息64中将质询mac 58、数据mac 60和计数器mac 62以及质询48、附加认证数据和第一计数器从后台16发送到编程工具14。在确定第一类型的认证的情况下,消息64相反可以包括质询mac 58。通过利用质询mac 58 (即,会话密钥)签名第一常数,编程工具14可以根据包括在消息64内的信息来生成响应mac 68。不管认证是第一类型还是第二类型的,都可以生成响应mac 68,即,响应mac 68内包含的信息可以用于本文所构想的两种认证。第一常数可以用于生成附加密钥,以便针对不同阶段使用不同密钥来分离,作为附加安全措施。示例性响应mac 68如下所示。
66.(session key:会话密钥,first constant:第一常数)编程工具14可以例如利用0x27发送密钥请求将相应的请求72发送到ecu 12。ecu 12处理发送密钥请求72以确定是需要第一还是第二类型的认证,使得与其相关联的判定有效地完成质询认证46。发送密钥请求72可以包括数据mac 60、计数器mac 62和/或响应mac 68,以及质询48、附加认证数据、第一计数器和第一常数。响应mac 68可以可选地限制为x个最高有效字节(most significant byte),以提供附加的安全选项,即,x可以被设置为12或其他数量,以便根据闯入者可能未知的设计参数来限制正使用的最高有效字节。
67.响应于接收到响应消息72,ecu 12可以通过计算其自身的在发送密钥请求72中接收的信息的值并且然后将其计算结果与在发送密钥请求72中接收的信息/值进行比较来执行匹配操作。质询认证46可以使用匹配的数量(如果有的话)来决定是否应该准许安全访问,并且如果准许安全访问,则决定是否需要第一或第二类型的认证。本公开的一个非限制性方面构想到ecu比较mac质询58的y (例如16)个最高有效字节和响应mac 68的12个最高有效字节,目的在于执行匹配操作。可选地,最初可以执行匹配操作,其中ecu 12计算其值而不设置质询48的最高有效位,即,计算质询mac 58,其中子函数的最高有效位未设置。
68.如果ecu 12在最高有效位未设置时计算的值与发送密钥请求72内接收的值相匹配,则ecu 12确定由于该匹配而安全访问得到验证,并且确定由于在子函数的最高有效位
未设置时发生的匹配而要执行第一类型认证。如果ecu 12计算的值与发送密钥请求72中的相应值不匹配,则ecu可以执行与被设置的子函数的最高有效位的另一匹配。如果该后续操作导致匹配,则ecu 12确定由于匹配而安全访问得到验证,并且确定由于在设置子函数的最高有效位时发生匹配而需要第二类型的认证。如果ecu 12在完成两个匹配操作之后未能获得匹配,则ecu确定安全访问未被验证,并拒绝执行软部件更新的安全访问请求。
69.ecu 12可以根据匹配操作的结果设置安全访问标记和附加认证要求标记,例如,当匹配被验证时将安全访问标记设置为真,当需要第一类型认证时将附加认证标记设置为假,以及当需要第二类型认证时将附加认证标记设置为真。ecu 12可以向编程工具14发送相应的响应76,例如利用0x27发送密钥响应,以通知编程工具14是否已经授权或拒绝安全访问,即,是否允许软部件更新。通过来自后台16的附加通信或包括在实用工具文件28内的信息,编程工具14可以知道是需要第一还是第二类型的认证。然而,如果编程工具14不知道,则发送密钥响应76可以可选地包括指示需要第一还是第二类型的认证的信息。
70.编程工具14可以响应地将计数器请求78发送到具有第一计数器的ecu 12。ecu 12然后可以存储第一计数器以标记何时生成与认证质询46相关联的信息。可以响应地发送计数器响应消息80以验证ecu 12接受第一计数器。编程工具14然后可以发送输入编程会话请求82,以向ecu 12指示开始软部件更新的意图。ecu 12可响应地生成输入编程会话响应84,其指示准备好开始软部件更新。在需要第二类型的认证来完成软部件更新的情况下,则编程工具14向ecu 12发送附加验证数据请求86。该附加验证请求86可以包括数据mac 60、附加验证数据和第二计数器,其中该第二计数器用于暂时识别请求86的定时。
71.ecu 12可以响应于附加认证数据请求86而开始数据认证过程88。数据认证过程88可以对应于ecu 12验证第二计数器是否大于第一计数器,并且如果是,则计算其自身的用于附加授权数据的数据mac,并且将其与数据mac 60进行比较。ecu 12可以通过利用附加认证密钥对附加认证数据进行签名来生成附加认证mac。附加认证密钥可以由ecu 12生成以模仿共享秘密,使得在ecu 12处确定的附加认证mac可以与从后台16接收的数据mac 60进行比较。例如可以通过利用存储在其中的解锁密钥或者可选地从其导出的密钥签名附加认证密钥常数来生成附加认证密钥。
72.在匹配的情况下,ecu 12确定从编程工具14提供的附加认证数据是有效的。ecu 12可以随后响应地存储对应于模块id的软部件的一些或全部消息摘要,用于促进更新ecu 12的存储器。当ecu 12确定在后台16生成的附加验证数据被正确接收时,即,自从后台16传输以来已经被验证为未被篡改时,ecu 12可以将附加验证数据响应92发送到编程工具14。
73.数据传送过程94可以开始于ecu 12中的编程工具14交换响应和请求消息,由此将软部件提供给ecu 12,并且ecu 12作为响应擦除分区并且以其他方式促进其下载。在安装软部件和/或允许其被执行之前,模块验证过程100可以对应于ecu 12验证所提供的软部件的真实性,例如通过生成所提供的软部件的消息摘要并将其与由编程工具14提供的存储的软部件消息摘要相比较,存储的软部件消息摘要对应于ecu 12上包括的模块id,另外验证软部件的签名是有效的。模块id可以用于识别需要更新的ecu 12的特定分区或其他方面,并且由此在ecu 12允许安装软件之前,对其的验证可以是有用的最后步骤。ecu 12可以在验证更新时发送传送数据响应102。
74.具体实施方式和附图或图对于本教导而言是支持性和描述性的,但是本教导的范
围仅由权利要求限定。虽然已经详细描述了用于执行本教导的一些最佳模式和其他实施例,但是存在用于实践在所附权利要求中限定的本教导的各种替代设计和实施例。此外,本公开明确地包括上文和下文呈现的元件和特征的组合和子组合。
技术特征:
1.一种认证电子控制单元(ecu)的软部件更新的方法,包括:确定被包括在从编程工具发送到所述ecu的发送密钥请求内的发送密钥信息;以及从所述发送密钥信息识别所述软部件更新是要根据第一类型的认证还是第二类型的认证来认证,所述ecu被配置为执行所述第一类型和所述第二类型两者,所述第一类型允许所述ecu响应于完成解锁密钥认证而更新,所述第二类型允许所述ecu响应于除了完成所述解锁密钥认证之外还认证为所述软部件创建的消息摘要而更新。2.根据权利要求1所述的方法,还包括:要求所述ecu执行质询认证以便确定是根据所述第一类型还是所述第二类型来认证所述更新,当所述质询认证不成功时,要求所述ecu根据所述第一类型进行认证,并且当所述质询认证成功时,要求所述ecu根据所述第二类型进行认证。3.根据权利要求2所述的方法,还包括:当所述ecu生成质询消息认证码(mac)和响应mac并且将所述质询消息认证码和所述响应mac两者匹配到包括在所述发送密钥信息内的对应的质询和响应mac时,确定所述质询认证成功。4.根据权利要求3所述的方法,还包括:要求所述ecu通过利用解锁密钥对质询进行签名来生成所述质询mac。5.根据权利要求4所述的方法,还包括:通过在将子函数与种子级联之前设置所述子函数的最高有效位来要求所述ecu生成所述质询,所述ecu通过将ecu标识符(id)与随机数级联来生成所述种子。6.根据权利要求5所述的方法,还包括:要求所述ecu通过利用会话密钥对第一常数签名来生成所述响应mac。7.根据权利要求6所述的方法,还包括:将利用所述ecu生成的质询mac的不多于x个最高有效位与包括在所述发送密钥信息内的质询mac进行匹配。8.根据权利要求7所述的方法,还包括:将利用所述ecu生成的所述响应mac的不多于y个最高有效位与包括在所述发送密钥信息内的所述响应mac进行匹配。9.根据权利要求8所述的方法,还包括:选择所述x为16和所述y为12,使得所述质询mac的16个最高有效位匹配,并且所述响应mac的12个最高有效位匹配。10.根据权利要求6所述的方法,还包括:在所述质询认证之后在更新所述软部件之前,要求所述ecu完成数据认证和模块认证中的每一者。
技术总结
本公开涉及一种用于验证电子控制单元(ECU)或其他处理装置的软部件更新的方法和系统。验证可以包括后台向编程工具提供验证数据,由此ECU与编程工具交互以验证软部件更新。认证可以可选地包括ECU根据不同类型的认证来识别是否要认证软部件更新。识别是否要认证软部件更新。识别是否要认证软部件更新。
技术研发人员:B
受保护的技术使用者:通用汽车环球科技运作有限责任公司
技术研发日:2022.10.20
技术公布日:2023/9/25
版权声明
本文仅代表作者观点,不代表航家之家立场。
本文系作者授权航家号发表,未经原创作者书面授权,任何单位或个人不得引用、复制、转载、摘编、链接或以其他任何方式复制发表。任何单位或个人在获得书面授权使用航空之家内容时,须注明作者及来源 “航空之家”。如非法使用航空之家的部分或全部内容的,航空之家将依法追究其法律责任。(航空之家官方QQ:2926969996)
航空之家 https://www.aerohome.com.cn/
航空商城 https://mall.aerohome.com.cn/
航空资讯 https://news.aerohome.com.cn/