CN113016201A - 密钥供应方法以及相关产品 - Google Patents

密钥供应方法以及相关产品 Download PDF

Info

Publication number
CN113016201A
CN113016201A CN202080005150.5A CN202080005150A CN113016201A CN 113016201 A CN113016201 A CN 113016201A CN 202080005150 A CN202080005150 A CN 202080005150A CN 113016201 A CN113016201 A CN 113016201A
Authority
CN
China
Prior art keywords
provisioning
key
access
request
vehicle
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN202080005150.5A
Other languages
English (en)
Other versions
CN113016201B (zh
Inventor
姜锡忎
魏卓
钟胤
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Publication of CN113016201A publication Critical patent/CN113016201A/zh
Application granted granted Critical
Publication of CN113016201B publication Critical patent/CN113016201B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/041—Key generation or derivation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/065—Network architectures or network communication protocols for network security for supporting key management in a packet data network for group communications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/083—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP]
    • H04L9/0833—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP] involving conference or group key
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0891—Revocation or update of secret information, e.g. encryption key update or rekeying
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • H04L9/3213—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority using tickets or tokens, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/069—Authentication using certificates or pre-shared keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/60—Context-dependent security
    • H04W12/61—Time-dependent
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H04W4/48—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P] for in-vehicle communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/84—Vehicles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Lock And Its Accessories (AREA)

Abstract

提供了一种密钥的供应方法和相关产品。在该方法中，第一设备从第二设备接收用于请求访问第一设备的访问请求；确定是否允许第二设备访问第一设备；基于该确定，向第二设备发送访问响应；从第二设备接收第一供应消息；根据供应数据生成组密钥。根据本公开提供的解决方案，可以借助于包含供应数据的一个供应消息来向车辆中的所有ECU设备供应组密钥。这样，提高了密钥供应的效率，并且降低了供应成本。通过使用生成的组密钥，可以确保与ECU设备关联的数据通信的安全性。

Description

密钥供应方法以及相关产品
技术领域
本公开涉及V2X技术领域，尤其涉及一种密钥供应方法以及相关产品。
背景技术
车辆到外界(vehicle-to-everything，V2X)，可以指车辆到车辆(vehicle-to-vehicle，V2V)和车辆到基础设施(Vehicle-to-infrastructure，V2I)通信，是一种旨在实现车辆与其周围环境之间数据交换的无线技术。
在与V2X技术相关的多种应用程序中，车辆的安全性问题吸引了越来越多的注意力，其中一个问题可能就是车辆的密钥供应。密钥供应表示将初始秘密密钥设置到车辆内部设备的具体工作。有时，密钥供应过程也称为“密钥设置”、“密钥分配”、“密钥初始化”或“密钥配置”，其中密钥意味着一些用于数据机密性和完整性或用于保护其他秘密密钥的秘密信息。除非另有说明，否则这些术语在本文中以可互换的方式使用。
随着网络攻击者的增多，这些密钥的设置已变得至关重要。特别地，每个车辆必须具有唯一的密钥，以减少安全影响，即，即使攻击者获得了车辆的密钥，它也不应影响其他车辆。另外，当前的车辆具有用于自动驾驶和联网汽车功能的大量设备和应用，并具有以网关为基础的分离网络，以提高安全性。因此，它需要为每个设备设置许多秘密密钥。
提供该背景信息以揭示申请人认为与本公开可能相关的信息。无需意图也不应解释为承认任何前述信息构成了针对本公开的现有技术。
发明内容
鉴于此，为了解决上述问题，本公开提供了一种密钥供应方法及相关产品。
上述和其他目的是通过独立权利要求的主题实现的。根据从属权利要求、说明书和附图，进一步的实现形式是显而易见的。
本公开的第一方面涉及一种密钥供应方法，由第一设备实现，其中，所述第一设备安装在车辆中，并且所述方法包括：从第二设备接收用于请求访问所述第一设备的访问请求；基于所述访问请求确定所述第二设备是否被允许访问所述第一设备；基于所述确定向所述第二设备发送访问响应；从所述第二设备接收第一供应消息，其中，所述第一供应消息包括用于生成组密钥的供应数据，并且所述组密钥在所述车辆中的第一设备之间共享；以及根据所述供应数据生成所述组密钥。
根据本公开提供的解决方案，可以借助于包含供应数据的一个供应消息来向所有第一设备(例如，车辆中的所有ECU设备)供应组密钥。这样，提高了密钥供应的效率，并且降低了供应成本。通过使用生成的组密钥，可以确保与ECU设备相关的数据通信的安全性。此外，由于在ECU设备上自动生成了密钥，因此减少了具有有限信息的数据大小，并且还可以同时设置多个设备的密钥。应当注意，第一设备可以是安装在车辆中的任何设备，出于说明目的，在说明书中仅以ECU设备为例。此外，这里的组密钥在同一车辆的第一设备之间共享，但是不同车辆上的第一设备具有不同的组密钥。
在根据第一方面的方法的一种可能的实现形式中，所述基于所述访问请求确定所述第二设备是否被允许访问所述第一设备包括：向所述第二设备发送用于验证所述第二设备的权限的认证请求；从所述第二设备接收与所述认证请求匹配的访问令牌；确定接收到的所述访问令牌是否有效；其中，基于所述确定向所述第二设备发送所述访问响应包括：当确定接收到的所述访问令牌有效时，向所述第二设备发送肯定访问响应；以及当确定接收到的所述访问令牌无效时，向所述第二设备发送否定访问响应。
基于令牌的认证不仅提供了车辆设备与KMS服务器之间的端到端安全性，而且还提供了每个车辆的密钥独立性以及来自KMS签名的密钥认证。
在根据第一方面的方法的一种可能的实现形式中，所述方法还包括：在触发所述访问请求时，向所述第二设备发送第一供应响应；以及从所述第二设备接收用于为所述第一设备供应功能秘密密钥的供应请求；基于所述组密钥和预先存储数据生成所述功能秘密密钥；以及向所述第二设备发送第二供应响应。
可以基于所生成的组密钥进一步生成功能密钥，并且该功能密钥可以是由某个特定组的每个ECU(可以其区分为其应用或目的，例如安全车载通信(secure on-boardcommunication，SecOC)和传输层安全(transport layer secure，TLS))自动生成功能的密钥，使ECU设备在功能上的区分成为可能，为车辆安全通信中提供了更大的灵活性。
在根据第一方面的方法的一种可能的实现形式中，所述方法还包括：从第三设备接收密钥确认质询，其中，所述密钥确认质询是在从所述第二设备接收到用于确认所述功能秘密密钥是否正确生成的确认请求时由所述第三设备发送的；根据所述密钥确认质询、所述功能秘密密钥和第二预定义算法，生成密钥确认响应；以及向所述第三设备发送所述密钥确认响应。
当ECU设备生成功能秘密密钥时，所生成的功能秘密密钥应由网关进行验证，以确保ECU设备正确生成功能秘密密钥
本公开的第二方面涉及一种密钥供应方法，由第二设备实现，包括：向第一设备发送用于请求访问所述第一设备的访问请求，其中，所述第一设备安装在车辆中；从所述第一设备接收访问响应，其中，所述第一设备基于所述访问请求返回所述访问响应；以及向所述第一设备发送第一供应消息，其中，所述第一供应消息包括用于由所述第一设备生成组密钥的供应数据，并且所述组密钥在所述车辆中的第一设备之间共享。
在根据第二方面的方法的一种可能的实现形式中，在向所述第一设备发送用于请求访问所述第一设备的访问请求之前，所述方法还包括：向服务器发送用于请求与所述组密钥对应的访问令牌的令牌请求，其中，所述令牌请求中包括所述第二设备计划供应的一个或多个车辆的标识，所述车辆中包括所述第一设备所属的车辆；以及从所述服务器接收与所述组密钥对应的访问令牌和与所述访问令牌相对应的第二供应消息。
在根据第二方面的方法的一种可能的实现形式中，在从所述第一设备接收所述访问响应之前，该方法还包括：从所述第一设备接收用于验证所述第二设备的权限的认证请求；以及确定与所述认证请求匹配的访问令牌；以及向所述第一设备发送所述与认证请求匹配的访问令牌。
在根据第二方面的方法的一种可能的实现形式中，其中，所述确定与所述认证请求匹配的访问令牌包括：根据所述认证请求，确定所述第一设备的供应状态；以及在确定所述第一设备没有生成所述第一设备的所述组密钥时，使用与所述组密钥对应的访问令牌作为所述与所述认证请求匹配的访问令牌。
在根据第二方面的方法的一种可能的实现形式中，其中，所述从所述第一设备接收所述访问响应包括：从所述第一设备接收否定访问响应；在向所述第一设备发送所述第一供应消息之前，所述方法还包括：向所述服务器发送令牌更新请求，用于更新所述第一设备的访问令牌；以及从所述服务器接收更新后的访问令牌作为与所述组密钥对应的访问令牌。
在根据第二方面的方法的一种可能的实现形式中，所述方法还包括：从所述第一设备接收第一供应响应；当所述第一供应响应指示所述第一设备成功生成了所述组密钥时，发送用于为所述第一设备供应功能秘密密钥的供应请求；以及从所述第一设备接收第二供应响应。
在根据第二方面的方法的一种可能的实现形式中，向所述服务器发送用于请求所述第一设备的替换设备的访问令牌的请求；从所述服务器接收与所述组密钥对应的访问令牌；以及使用接收到的所述访问令牌来供应所述替换设备。在可能的实现中，所述访问令牌可以包括所述替换设备的标识，从而所述第二设备可以使用所述访问令牌来访问所述替换设备。在此，所述替换设备的供应可以与所述第一设备的供应以相同的方式进行。
在根据第二方面的方法的一种可能的实现形式中，所述方法还包括：向所述服务器发送用于请求更新第一设备的功能秘密密钥的功能秘密访问令牌的请求，接收所述功能秘密访问令牌和来自所述服务器的相应更新数据；以及更新所述第一设备的所述功能秘密密钥。在此，所述功能秘密密钥的更新可以与用于所述第一设备的所述功能密钥的供应以相同的方式进行。
本公开的第三方面涉及一种密钥供应方法，由服务器实现，包括：从第四设备接收用于配置第一设备的配置请求，其中，所述配置请求包括所述第一设备所属车辆的标识，且所述第一设备安装在车辆中；向所述第四设备发送本地供应数据，其中，所述本地供应数据用于生成所述第一设备的组密钥，并且所述组密钥在所述车辆中的第一设备之间共享。
本公开的第四方面涉及一种安装在车辆中的第一设备，所述第一设备包括接收模块、确定模块、发送模块和生成模块。所述接收模块用于从第二设备接收用于请求访问所述第一设备的访问请求；所述确定模块用于基于所述访问请求，确定所述第二设备是否被允许访问所述第一设备；所述发送模块用于基于所述确定，向所述第二设备发送访问响应；所述接收模块还用于从所述第二设备接收第一供应消息，其中，所述第一供应消息包括用于生成组密钥的供应数据，所述组密钥在所述车辆的第一设备之间共享；所述生成模块用于根据所述供应数据生成所述组密钥。
本公开的第五方面涉及一种第二设备，包括发送模块和接收模块。所述发送模块用于向第一设备发送用于请求访问所述第一设备的访问请求，其中，所述第一设备安装在车辆中；所述接收模块用于从所述第一设备接收访问响应，其中，所述第一设备基于所述访问请求返回所述访问响应；所述发送模块还用于向所述第一设备发送第一供应消息，其中，所述第一供应消息包括用于由所述第一设备生成组密钥的供应数据，所述组密钥在所述车辆的第一设备之间共享。
本公开的第六方面涉及一种服务器，包括接收模块和发送模块。所述接收模块用于从第四设备接收用于配置第一设备的配置请求，其中，所述配置请求包括所述第一设备所属车辆的标识，并且所述第一设备安装在所述车辆中；所述发送模块用于向所述第四设备发送本地供应数据，其中，所述本地供应数据用于生成所述第一设备的组密钥，所述组密钥在所述车辆的第一设备之间共享。
本公开的第七方面涉及一种第一设备，包括存储器、处理器、输入接口和输出接口。所述存储器、所述处理器、所述输入接口和所述输出接口通过总线系统连接。所述存储器用于存储指令，并且所述处理器用于执行存储在所述存储器中的所述指令，以执行上述第一方面或第一方面的任何可能的实现中的方法。
本公开的第八方面涉及一种第二设备，其包括存储器、处理器、输入接口和输出接口。所述存储器、所述处理器，所述输入接口和所述输出接口通过总线系统连接。所述存储器用于存储指令，并且所述处理器用于执行存储在所述存储器中的所述指令，以执行上述第二方面或第二方面的任何可能的实现中的方法。
本公开的第九方面涉及一种服务器，包括存储器、处理器、输入接口和输出接口。所述存储器、所述处理器、所述输入接口和所述输出接口通过总线系统连接。所述存储器用于存储指令，并且所述处理器用于执行存储在所述存储器中的所述指令，以执行上述第三方面或第三方面的任何可能的实现中的方法。
本公开的第十方面涉及一种存储计算机可执行指令的计算机存储介质，所述计算机可执行指令在被执行时实现根据本公开的第一、第二或第三方面及其任何可能的实现中的方法。
提供了本公开的第十一方面涉及一种计算机程序产品，包括指令，当所述指令在计算机上执行时，使计算机执行上述第一、第二或第三方面或去任何可能的实现中的方法。
附图说明
图1示出了由本公开的实施例提供的密钥。
图2a示出了根据本公开实施例的密钥供应系统。
图2b示出了根据本公开实施例的关于图2a所示的密钥供应系统的一般供应过程。
图3a和图3b示出了根据本公开实施例的密钥供应方法中的第一设备配置的流程示意图。
图4a和图4b示出了根据本公开实施例的密钥供应方法中的第二设备配置的流程示意图。
图5示出了根据本公开实施例的密钥供应方法中的自密钥生成的流程示意图。
图6a至图6c示出了根据本公开实施例的密钥供应方法中的自密钥生成的流程示意图。
图7a示出了根据本公开实施例的功能秘密密钥的生成的流程示意图。
图7b示出了根据本公开实施例的功能秘密密钥的示例。
图8示出了ECU设备处的自密钥生成器的示例性结构。
图9a和图9b示出了根据本公开实施例的在密钥供应方法中基于令牌的认证的流程示意图。
图10示出了根据本公开实施例的访问令牌的示例性结构。
图11示出了用于ECU设备或网关的认证逻辑。
图12示出了根据本公开实施例的用于验证认证和授权的示例性过程。
图13和图14示出了经销商供应工具的示例性用例。
图15示出了根据本公开实施例的第一设备的结构示意图。
图16示出了根据本公开实施例的第二设备的结构示意图。
图17示出了根据本公开实施例的服务器的结构示意图。
图18是根据本公开实施例的第一设备的示意性框图。
图19是根据本公开实施例的第二设备的示意性框图。
图20是根据本公开实施例的服务器的示意性框图。
具体实施方式
在以下描述中，参考构成公开的一部分的附图，这些附图以说明的方式示出了本公开的实施例的具体方面或其中可以使用本公开的实施例的具体方面。应当理解的是，本公开的实施例可以在其他方面使用，并且包括在附图中未示出的结构或逻辑变化。因此，以下详细描述不应被视为限制性意义，并且本公开的范围由所附权利要求限定。
如背景部分中所述，车辆中的电子控制单元(electronic control unit，ECU)设备的密钥供应非常重要。秘密密钥可以防止攻击者窃听通道和操纵任意消息，并提供基本的系统安全性。秘密密钥的安全范围包括(但不限于)：
1)车辆内部和外部的通信安全性：ECU设备之间的使用秘密密钥或建立安全连接进行消息加密和验证，例如，安全车载通信(SecOC)和传输层安全(TLS)/数据报传输层安全性(Datagram Transport Layer Security，DTLS)。
2)系统和软件完整性检查：通过验证固件或引导加载程序，使用密钥进行远程认证，或者更新捆绑包解密和完整性检查，以进行安全的空中更新和安全的重新编程。
需要说明的是，以上应用场景仅是为了举例说明本公开实施例，而不应理解为是对本公开的限制。
现有各种针对密钥供应的解决方案。具体而言，现有解决方案着重于为“单个设备”供应唯一密钥。密钥供应方法使用对称密钥，该对称密钥由消息的发送者和接收者共享和使用，以对消息进行加密和解密。密钥生成服务器为硬件设备选择随机的设备唯一密钥，并使用嵌入在每个硬件设备中的共享密钥对设备唯一密钥进行加密，以便只有硬件设备才能解密设备唯一密钥。因为每个设备都有不同的密钥，所以服务器应为许多设备发出不同的加密消息。
另一种解决方案取决于片上密钥的假设，片上密钥由芯片制造商以加密形式将供应密钥存储在安全的位置。因此，它依赖于在较早的制造步骤中预先存储的其他密钥。供应密钥本身可以使用片上密钥进行加密，并以加密形式以加密形式发送至“设备制造商”。因此，该供应密钥是由“处理器制造商”决定的。
现有的解决方案提供了侧重于设备制造商来设置自己的供应密钥的方法，而我们的新思路提供的方法主要侧重于“车辆制造商”，以基于自生成的密钥来为车辆上的许多设备设置车辆密钥。因此，可以在执行我们的解决方案之前在较早的阶段采用现有解决方案。我们可以采用供应商制造的现有方法来在车辆制造之前将供应密钥存储到每个ECU设备中。
但是，现有解决方案可能有其自身的局限性。例如：
1)将它们部署在一台设备上。
因为时间是车辆制造系统中最重要的事情之一。如果将其部署在具有许多设备的车辆上，则将需要花费大量时间来设置每个设备。如果我们想完善或扩展那些现有的解决方案以应用于车辆方面，则必须设计一种能够节省时间的新协议和系统。
2)它们基于密钥分配，作为服务器中每个设备的加密密钥。
每个设备都需要大量具有加密形式的消息，因此，在为每个设备分配加密消息时，它将增加通信流量。因此，它将另外增加一些延迟。此外，管理服务器和中间工具还需要管理复杂的配置数据。
3)它们需要直接在线连接到服务器
制造系统应根据预定的时间和流程准确地执行生产过程。通常，工厂没有这种安全密钥存储，因此，它需要连接外部安全密钥服务器。依赖实时连接为每个设备获取新密钥可能不适合生产计划，因为很难期望制造系统在生产过程中始终可靠地连接到在线服务器。
针对这种问题，目标是为车辆中的设备(即，车辆中的所有ECU设备)安全地设置初始唯一组密钥，因此，属于其他车辆的设备无法知道那些密钥。该技术需要大量时间来为每个车辆的每个设备设置密钥，并且需要具有不同设备状态的复杂密钥管理协议，例如它们的嵌入式默认密钥和所需的密钥。此外，需要耗费大量的管理系统来收集和管理来自批量供应商的设备信息。需要说明的是，车辆中的设备可以是ECU设备以外的设备，本公开对此不做限定。
本公开提供了一种密钥供应方法和相关产品。首先，本公开提供了用于向车辆的ECU设备安全地供应密钥的方法，以及用于验证供应工具、系统和接收到的消息的认证方法，从而实现安全的密钥设置(认证的密钥供应)。其次，本公开针对车辆的所有设备使用仅具有一个消息的密钥的自生成。即使将其部署在许多设备和许多车辆上，它也有助于降低流量开销、减少网络传输和降低操作延迟，从而以最小的延迟实现快速的操作。第三，本文提供的解决方案具有可扩展性，可通过车辆标准协议部署许多密钥。实际上，本公开通过应用用于供应工具“基于令牌的认证”，不需要到服务器在线连接，这允许在不依赖在线连接的情况下访问ECU设备。此外，它通过标准汽车协议为每种车辆配置仅提供一条消息即提供了可扩展性。这反映了实际的车辆生产和经销商或机械环境，其中，需要对各种系统和利益相关者进行简单地管理。
在下文中，将参考附图详细描述本公开的实施例。
在阐述本公开的详细实施方式之前，首先简要说明在此可以使用的几个密钥。
本文描述的方法可以在以下假设下开始，其中每个设备安全地保存供应密钥(provisioning key，PVK)作为预共享的秘密密钥，PVK也称为组密钥，这两个术语在可交换中使用。除非另有说明。通过提出的方法，每个ECU设备将获得两种秘密密钥：1)组密钥，也称为车辆专用密钥(vehicle-specific secret key，VSK)和2)功能秘密密钥(functionalsecret keys，FSK)。
PVK通过供应商生产与所有ECU预共享，例如，可以通过供应商端的供应工具注入PVK。PVK通常可以从车辆制造商(OEM)获得，有关PVK分配的政策可以由OEM专门决定和管理。在一种可能的实现中，我们假设PVK根据车辆类型或型号而有所不同。
VSK由车辆中的每个ECU自动生成，例如，使用PVK和从KMS(key managementsystem，密钥管理系统)接收到的一些随机字符串。每个车辆的VSK均不同(VIN唯一)。
FSK由某个特定组的每个ECU自动生成，例如，使用VSK和预定义的特定字符串和值。可以将这些组区分为其应用程序或目的，例如安全车载通信(SecOC)和传输层安全(TLS)。
OEM的公钥(用于密钥管理系统(KMS))用于验证收到的供应数据。
如图1所示，对于车辆1中的设备，所有设备共享一个VSK1，设备被分为两组，每个组具有一个FSK，即FSK1和FSK2；对于车辆2中的设备，所有设备共享一个VSK2，并且没有为这些设备供应FSK。由于车辆之间的VSK不同，因此，VSK1不等于VSK2。
图2a示出了根据本公开实施例的密钥供应系统，并且图2b示出了根据本公开实施例的关于图2a所示的密钥供应系统的一般供应过程。
如图2a所示，密钥供应系统可以由三个主要方面组成，包括OEM KMS、供应商工厂供应系统和车辆侧的供应工具。首先，KMS负责生成供应消息。供应工具负责将该消息发送到设备。由于供应工具没有有关密钥的任何信息，因此该工具无法安全访问设备。“访问令牌”允许供应工具获得对车辆设备的访问权限。它也由KMS提供，只能使用一次，并且只能用于密钥设置。每个设备都可以使用“计数器”值检查当前的供应状态，每当密钥供应状态更改时，该值都会增加。计数器和访问令牌将在后面部分中描述。
KMS负责配置ECU设备以及配置供应工具。在供应商端，ECU设备是在ECU生产期间(供应商生产阶段)在供应商工厂供应系统中配置的。供应工具是用于设备诊断的典型设备或程序，可以是硬件设备或软件程序，例如OEM侧专用车辆测试设备、经销商诊断工具/扫描仪或运行在便携式设备(移动电话和平板电脑)上的应用程序。供应工具通常不了解上述任何密钥。本文引入该术语只是为了便于描述，并且对供应工具没有特定限制。
图2b示出了系统组件和关系。在该图中，假定例如使用现有技术在供应商与KMS服务器之间以及在供应工具与KMS服务器之间建立安全通道。这些安全通道的建立不是本公开的重点。我们假设必须至少有一个安全通道，例如TLS和供应商管理系统(ECU供应商工厂供应系统)。因此，它们可以在第一步和第二步中共享一些信息。关于这方面的安全考虑，我们将在后面部分中描述。此外，图2b中的虚线框是指从其他方获取的信息，并且实线框是指已经预存的本地信息。
有四种主要组成部分。整体安全性取决于管理供应数据、验证密钥和访问令牌的KMS。供应商系统(图2a和图2b中所示的ECU供应商工厂供应系统)还具有安全工具，以将特定信息(例如有关密钥、时间戳、车辆和设备)注入其产品。ECU设备产品应具有一些受保护的存储器，以安全地保留供应密钥和自生成功能。例如，设备应具有基于分层存储管理(hierarchical storage management，HSM)或可信执行环境(trusted executionenvironment，TEE)的安全存储。测试工具(也称为供应工具/系统，除非另有说明，否则这两个术语以可交换的方式使用)仅有从KMS接收的访问令牌和供应消息。它的主要作用是将供应消息传递给ECU。
供应过程分为三个步骤：1)ECU配置、2)供应工具配置以及3)自密钥生成。第一步是在KMS和供应商工厂供应系统之间实现的，该系统用于供应商生产中的设备配置，其中，一些工程师或系统会将秘密信息注入ECU内部。在KMS与供应工具之间实现的第二步中，KMS将为供应工具提供用于车辆密钥设置的供应数据。供应工具的主要作用只是将这些数据发送到ECU设备。作为在供应商工厂供应系统和供应工具之间实现的最后一步，使用接收到的供应数据在每个设备上执行自密钥生成，以获得VSK和FSK。
用于车辆的ECU设备的整个供应过程可以如下：
1)供应商生产工具将其本地供应数据导入其产品，例如，本地供应数据可能包括供应密钥、OEM的公钥、时间戳、其他车用信息。需要说明的是，本文所列举的上述数据只是为了说明的目的，具体实现将在下面的实施例中进行说明。
2)供应工具使用从KMS接收到的访问令牌获得对车辆所有ECU的访问，并向其发送供应消息。
3)车辆中的每个ECU都使用供应工具发送的供应消息自行生成车辆专用秘密密钥，并通过签名和公钥进行验证。
4)车辆中的每个ECU基于自行生成的和通过验证的车辆专用秘密密钥自行生成其他功能秘密密钥。
5)车辆的网关确保每个ECU完成密钥供应过程，并通过供应工具将结果通知服务器。
6)除网关(gateway，GW)之外，所有ECU都删除了供应密钥和密钥自生成功能。
本公开提供的密钥供应方法将结合图2b所示的详细信息进行描述。
图3a和图3b示出了根据本公开实施例的密钥供应方法中的第一设备配置的流程示意图。图3a和图3b示出了在前述第一步中的具体处理过程，供应商生产中的ECU配置。该方法可以由OEM侧的服务器和供应商侧的供应商设备(在后面的描述中也称为第四设备，除非另外指明，否则这两个术语以可交换的方式使用)执行。该流程图涉及图2a和图2b所示的第一步，并起到配置ECU设备的作用，并且第一设备可以是图2b所示的ECU设备。
假定该过程在供应商制造系统中执行。此外，如前所述，假定服务器(OEM KMS)和供应商设备(由供应商制造系统提供)进行相互认证以相互验证并建立用于安全通信的安全通道。
该方法可以包括：
S301：供应商设备向服务器发送配置请求，以配置第一设备，服务器从供应商设备接收配置请求。
通过建立的安全通道，供应商设备向KMS服务器发送配置请求，该配置请求可以包括第一设备所属的车辆的标识，即安装第一设备(图2a所示的ECU设备)的车辆。
示例性地，供应商设备还可以在配置请求中包括补充信息，即关于产品的信息，例如车辆类型、产品类型和供应商标识，以便获得ECU设备的本地供应数据。
在实际应用中，KMS服务器可以定义分布供应数据的策略，该策略可能会根据OEM的选择而有所不同。
S302：服务器向供应商设备发送本地供应数据，并且供应商设备接收本地供应数据。
示例性地，参照图2b，在获得车辆的标识后，KMS服务器可以响应与ECU设备匹配的适当的供应数据，即，向供应商设备提供本地供应数据，其中，本地供应数据可以包括1)供应密钥(图2b中所示的供应密钥)，2)公钥(图2b中所示的OEM公钥，在ECU中也称为标志验证密钥)和3)本地时间戳，其中，供应密钥用于在以后的阶段为ECU设备生成组密钥；公钥用于验证提供供应工具的第二设备的权限，该供应工具向ECU设备发送供应消息，它实际上是用于验证以确保所接收的消息最初是由KMS生成的；并且本地时间戳用于验证所生成的供应密钥的有效性，它实际上是为了新鲜度，不允许过时或重播的消息，作为一种可能的实现，本地时间戳可以是当前时间。
S303：供应商设备将本地供应数据注入第一设备。
注入可以使用供应商自己的安全方法(例如安全调试工具)来完成。第一设备将数据存储在受保护的存储器中，例如由HSM或TEE提供的安全存储。
相应地，在第一设备侧，第一设备可以获取本地供应数据。
示例性地，如图2b所示，供应商设备和服务器可以在基于某种协议(例如TLS或超文本传输协议安全(Hyper Text Transfer Protocol Secure，HTTPS))建立的安全通道上进行通信，并且用ECU供应商工厂供应系统实现的供应商设备可以接收供应密钥和OEM公钥，然后将供应密钥、公钥和当前时间戳注入到ECU中，从而完成ECU设备的配置。
图4a和图4b示出了根据本公开实施例的密钥供应方法中的第二设备配置的流程示意图。图4a和图4b示出了在前述第二步骤中的具体处理过程，供应工具配置，以便为第二设备中提供的供应工具接入ECU设备做准备。图4b具体说明了与图4a相比的详细参数。如上所述，供应工具的主要作用是访问ECU设备并将从KMS服务器接收的供应数据传递给ECU设备。图4示出的流程在OEM侧进行，特别是在OEM侧的服务器与第二设备之间进行，该第二设备可以在OEM侧配备有供应工具。该流程图涉及图2a和图2b所示的第二步骤，以下描述中的第一设备可以是图2b中所示的ECU设备。此外，供应工具可以作为软件功能或硬件提供在第二设备中，或者供应工具可以实现为第二设备，因此供应工具的配置等同于第二设备的配置，在整个说明书中由第二设备完成的操作也可以被视为由供应工具完成的操作。
S401：第二设备向服务器发送用于请求与组密钥对应的访问令牌的令牌请求，并且服务器接收令牌请求。
S402：服务器向第二设备发送该令牌请求对应的访问令牌和与访问令牌对应的第二供应消息。
在访问第一设备之前，第二设备将首先获取与组密钥(VSK)相对应的访问令牌，第二设备将使用该访问令牌来访问第一设备，以便第一设备可以生成组密钥。
令牌请求可以包括第二设备计划供应的车辆的一个或多个标识，并且第一设备所属的车辆被包括在这些车辆中。在一个可能的实现中，令牌请求可以仅仅包括第一设备所属的车辆的一个标识。在另一个实现中，令牌请求可以包括第二设备计划供应的车辆的若干标识，并且第一设备所属的车辆被包括在这些车辆中。车辆的几种标识可以可选地采用列表的形式。
当令牌请求仅包括第一设备所属的车辆的一个标识时，服务器返回与第一设备所属的车辆的标识相对应的访问令牌和包含车辆的供应数据的第二供应消息。此外，第二设备也可能旨在为多个车辆进行供应，这样，第二设备可以在令牌请求中包括车辆标识列表，然后服务器可以依次向第二设备发送与令牌请求对应的访问令牌，以及包含车辆的供应数据的第二供应消息。通过使用该访问令牌，第二车辆可能能够访问列表中的车辆。
示例性地，如图2b所示，即使供应工具和KMS服务器都属于OEM，它们也可以在地理上分开，这意味着供应工具(可能是便携式设备或程序)与KMS服务器之间有物理距离，例如“工厂侧系统/工具”和“基于云的KMS服务器”。因此，KMS服务器和第二个设备需要安全通道来共享某些信息。如图2b所示，可以使用TLS和HTTPS来建立安全通道。所提出的方法还考虑了不受OEM控制的售后经销商测试工具(该用例将在后面部分进行描述)。
供应工具通过已建立的安全认证通道将用于供应数据的令牌请求和访问令牌发送到KMS服务器，同时发送供应车辆标识，以使服务器知道并确定要传输的数据。供应工具已经知道要供应哪些车辆，例如从制造管理系统、生产计划或直接访问车辆。它传输要访问以进行供应的车辆和ECU设备的列表。在确保请求者(第二设备)对目标车辆标识(VIN)具有授权后，服务器会生成正确的供应消息并将其发送到第二设备。服务器传输包含两种数据。
1)访问令牌：用于访问ECU设备(第一设备)。该工具将只有一个访问令牌，用于指定其可以访问的车辆。在一个可能的实现中，访问令牌还可以指定它可以访问哪些设备。具有不同结构的访问令牌可以实现不同的功能，这将在后面部分中进行描述。
2)供应数据：这是第二设备(或供应工具)应转发给第一设备进行供应的数据，每辆车仅分配一个消息。它可能包含以下数据：由供应密钥(指的是ECU中的供应密钥、PVK)加密的随机字符串、由供应密钥加密的供应时间戳(指从OEM服务器到ECU设备的当前时间戳)和验证签名，其中，随机字符串和供应时间戳可以用于ECU设备生成供应密钥，验证签名可以用于验证ECU设备生成的供应密钥的有效性。
在一个可能的实现中，随机字符串RSi和供应时间戳TSi可以被包括在密文Ci中。
如上所述，当令牌请求包括多个车辆标识时，服务器可以响应几个包含不同车辆的供应数据的第二供应消息，因此，在步骤S402中返回的供应数据可以用索引i表示，其中i表示目标车辆i的标识符(目标车辆标识)。例如，服务器返回的供应数据可以包括：由供应密钥加密的随机字符串RSi、由供应密钥加密的供应时间戳TSi和验证签名σi。服务器还可以在供应数据中的VIN-i(目标车辆的标识)，以便让第二设备知道哪个供应数据对应于哪个车辆，在这种情况下，验证签名σi表示VSKi、RSi和TSi的数据的签名，其中VSKi是ECU设备将通过专用车辆i的自密钥生成获得的所需密钥。可选地，服务器和第二设备还可以在配置供应工具之前，协商令牌请求与第二供应消息之间的对应关系，例如，当令牌请求包括多个标识时，服务器可以按预设的顺序回传第二供应消息，从而第二设备将知道哪个第二供应消息对应于哪个车辆，而无需将VIN-i包含在第二供应消息中包含的供应数据中。在这种情况下，验证签名σi表示VSKi、VIN-i、RSi和TSi的数据的签名。
利用上述方法，可以配置第二设备中的供应工具，并准备对目标车辆进行供应。
图5是根据本公开实施例的在密钥供应方法中自密钥生成的流程示意图。图5示出了上述第三步骤中的具体处理过程，基于供应数据的密钥生成。图5所示的流程在第一设备(ECU设备)和第二设备(配备有供应工具)之间进行的，特别是安装在车辆中的ECU设备与可以在OEM侧配备有供应工具的第二设备之间。该流程图涉及图2a和图2b所示的第三步骤以下描述中的第一设备可以是图2b中所示的ECU设备。应该注意的是，在进行图5所示的处理过程之前，第一设备已经利用图3a所示的方法进行配置，第二设备也已经利用图4a所示的方法进行了配置。
S501：第二设备向第一设备发送请求访问第一设备的访问请求，第一设备从第二设备接收访问请求。
在一种可能的实现中，访问请求可以仅仅是向第一设备写入数据的请求。该访问请求用于触发第一设备对第二设备的认证。
S502：第一设备确定第二设备是否被允许访问第一设备。
第一设备在接收到访问请求时，出于安全性考虑，第一设备可以确定是否允许第二设备访问第一设备。换句话说，访问权限的确定由访问请求触发。
S503：第一设备基于该确定，向第二设备发送访问响应，第二设备从第一设备接收访问响应。
在一种可能的实现中，当第一设备发现第二设备被允许访问第一设备时，它可以以肯定的响应进行响应，否则，可以以否定的响应进行响应。因此，第一设备基于访问请求返回访问响应。
S504：第二设备向第一设备发送第一供应消息，第一设备从第二设备接收第一供应消息。
在从第一设备接收到访问响应之后，第二设备可以将第一供应消息发送到第一设备。
如前所述，第一设备返回的访问响应可以是肯定响应，也可以是否定响应。在一种可能的实现中，当响应为肯定时，第二设备可以向第一设备直接发送第一供应消息；当响应为否定时，第二设备可以与服务器(例如，图2b中所示的KMS服务器)交互以更新其访问第一设备的权限。例如，第二设备可以更新其令牌，第二设备可以使用更新的令牌来访问第一设备。
S505：第一设备根据供应数据生成组密钥。
第一供应消息包括用于生成组密钥的供应数据，一旦第一设备从第二设备接收到第一供应消息，它就可以根据第一供应消息中包含的供应数据来生成组密钥(例如，图2a所示的VSK)。
需要说明的是，此处仅示出了一个第一设备的操作，在实际应用中，车辆中的所有ECU设备都可以执行相同的操作来生成组密钥。
此外，如将在下面部分中详细描述的那样，在实际应用中，ECU设备可能与车辆中的网关连接，在这种情况下，由于从外部传输到第一设备的数据或信息可能会首先与网关相遇，因此，在第一车辆为ECU设备的情况下，步骤S501中对访问请求的接收以及步骤S504中对第一供应消息的接收，应理解为间接接收，即，通过从网关转发的方式接收到这些类型的数据。
根据本公开，使第二设备能够访问车辆中的第一设备，并利用一个供应消息为车辆中的所有第一设备配置组密钥，从而降低流量开销、减少网络传输以及降低操作延迟，即使是针对许多设备和车辆进行部署。
在下文中，可以参考附图详细描述ECU设备的自密钥生成的详细实现。
在实际应用中，ECU设备可以与网关(GW)连接。网关表示与车载ECU设备连接的设备，并具有与外部设备(例如诊断程序)进行通信的接口。因此，第二设备在访问ECU设备时可能首先遇到网关。
因此，图2a和图2b所示的第三步骤可以基于ECU设备的位置以两种方式实现。图6a和图6b示出了如何在GW中完成第三步骤，图6c示出了普通ECU设备的流程。当供应工具尝试访问车辆时，它将首先遇到GW，并且需要通过GW才能访问车辆中的ECU设备。因此，GW应该成为车辆生产中的第一个供应目标。
图6a-图6c示出了根据本公开实施例的密钥供应方法的流程示意图。与图5a和图5b相比，在图6a和图6b中添加了更多具体的细节。应该注意的是，在进行图6a-图6c所示的处理过程之前，ECU设备已经用图3a所示的方法进行了配置，第二设备也已经利用图4a所示的方法进行了配置。
该方法可以包括：
S601：供应工具向网关发送请求访问网关的访问请求，网关从供应工具接收访问请求。
在触发访问请求时，访问请求可以仅仅是用于将数据写入第一设备的请求。
S602：网关确定是否允许供应工具访问网关。
在接收到访问请求之时，网关可以出于安全性的目的确定是否允许供应工具访问第一设备。该确定可以是网关和供应工具之间的基于令牌的认证。具体授权将在稍后参考图8a和图8b进行描述。
S603：网关基于该确定，向供应工具发送访问响应，供应工具从网关接收访问响应。
访问响应可以是肯定访问响应或否定访问响应。
在确定接收到的访问令牌有效时，网关将肯定访问响应发送到供应工具。当网关确定接收到的访问令牌无效时，向供应工具发送否定访问响应，当供应工具发送的访问令牌过期时，也可以这样做。
在供应工具侧，接收到否定访问响应可以指示供应工具具有用于供应网关的权限访问令牌，但是接收到否定访问响应可以指示供应工具没有权限访问令牌来供应网关，因此，在从网关接收到否定的访问响应时，供应工具可以向服务器发送令牌更新请求以更新网关的访问令牌，并从服务器接收更新的访问令牌作为与组密钥相对应的访问令牌。无论哪种情况，供应工具最终都能访问网关。
在服务器侧，在从第二设备接收到用于更新网关的访问令牌的令牌更新请求之后，服务器根据令牌更新请求将更新的访问令牌发送到供应工具。
S604：供应工具向网关发送第一供应消息，网关从供应工具接收第一供应消息。
在从第一设备接收到访问响应时，供应工具可以将第一供应消息发送到第一设备。
第一供应消息可以包括用于由网关生成组密钥的供应数据。
S605：网关根据供应数据生成组密钥。
供应数据可以包括由供应密钥加密的随机字符串，由供应密钥加密的供应时间戳和验证签名。
组密钥的生成方式可以如下：网关首先使用供应密钥对供应数据进行解密以获得随机字符串和供应时间戳，然后根据随机字符串和供应时间戳生成组密钥；网关在生成组密钥后，根据供应数据中的验证签名，对生成的供应密钥的有效性进行验证。
如前所述，除了组密钥(VSK)外，ECU设备还可以选择拥有FSK。以下步骤是可选的，可以根据实际需要执行。
S606：网关向供应工具发送第一供应响应，供应工具接收第一供应响应。
在生成组密钥之后，网关可以将响应发送到供应工具，以便供应工具知道是否成功生成了组密钥。
S607：当第一供应响应指示第一设备成功生成了组密钥时，供应工具发送用于为网关供应功能秘密密钥的供应请求，网关从第二设备接收供应请求。
S608：网关基于组密钥和预先存储的数据生成功能秘密密钥。
可以基于所生成的组密钥和一些预存储数据来完成FSK的生成。
网关(如果FKS是由网关生成的)或ECU设备(如果FKS是由ECU设备本身生成的)可以使用VSK和预定义的字符串来获取ECU专用的功能密钥和某些组专用的功能密钥。{ECUPart number,Unique ID,Serial number,and additional string(like“e2e”)}可以是ECU专用密钥(作为KMS服务器和ECU设备之间的端到端秘密密钥)的预定义字符串的一个示例。
图7a中示出了FSK生成的一个可能的实现。图7b中示出了FSK的示例。如图7a所示，其中，预设字符串可以是预先写入ECU设备中的一些数据，FSK的生成也可以基于车辆的标识(VIN)。密钥推导函数(key derivation function，KDF)的输出可以通过ECU设备中的签名进行验证。
VSK的示例可以是：具有诸如HMAC-SHA256的伪随机函数(pseudo randomfunction，PRF)的KDF(PVK，VIN||预定义字符串|RS||TS)。此外，功能密钥的示例可以是：KDF(VSK，VIN||预定义字符串)。
此外，图7b所示的如Pw(password，passphrase)、salt和迭代/成本因子的参数可以应用于如PBKDF2(RFC 8018，PKCS#5：基于密码的加密技术规范版本2.1)和scrypt(RFC7914，基于scrypt密码的密钥衍生函数)等KDF的示例中。
S609：网关向第二设备发送第二供应响应，供应工具从第一设备接收第二供应响应。
第二供应响应用于让供应工具知道网关是否成功生成了FSK。
S610：网关将生成的密钥路由到ECU设备。
在生成VSK和FSK之后，网关可以将生成的密钥路由到ECU设备。
在一种可能的实现中，在生成VSK和FSK之后，网关随后可以擦除与密钥供应有关的秘密信息，例如公钥和用于生成密钥的字符串。
为了更好地理解上述过程，请参考图6b。首先，从供应工具到设备的VSK供应请求(步骤S601中的访问请求)；例如，此供应请求可以是一种通过诊断消息(UDS，UnifiedDiagnostic Servic，统一诊断服务)进行的“写入数据”请求。随后，在完成基于令牌的认证之后，供应工具发送从KMS接收到的供应数据(类似于步骤S604)。一旦GW接收到此数据，它将1)对密文进行解密，以从消息中获取随机字符串和时间戳，2)使用解密后的数据生成VSK，以及3)验证生成的数据是否正确。如果这些过程成功完成，则供应工具将发送FSK供应请求，并要求ECU设备生成其他功能秘密密钥。当设备完成所有密钥生成后，它将删除与此自生成有关的供应数据和秘密信息。GW负责将接收到的数据路由到车辆中相应的ECU设备。
图6c示出了在ECU设备处进行供应的另一种可能情况，在这种情况下，网关通常将从供应工具接收的所有内容路由到ECU设备。基于令牌的认证以及组密钥和FSK的生成与图6a和图6b所示的相同，为了简洁起见，不再详细描述。
另外，关于VSK的生成，参考图2b，密钥生成是在每个ECU中使用“自密钥生成器”(可以在ECU设备上实现为软件功能)执行的，该“自密钥生成器”由KDF(密钥推导函数)、秘密密钥和预定义字符串组成和参数构成。有许多KDF，例如HKDF、PBKDF2和Scrypt。我们可以选择任何一个。除此之外，KDF还使用从外部来源接收到的其他输入字符串来为车辆生成独特的结果。图8示出了一些示例性字符串。
此外，典型ECU设备的流程类似于在GW中的方式，只是多了一个“密钥确认”的步骤，在该步骤中，GW确保ECU设备正确生成FSK，作为一种典型的质询响应认证。例如，ECU设备可以从网关接收密钥确认质询，其中，密钥确认质询是由网关在从供应工具接收到用于确认功能秘密密钥是否正确生成的密钥确认请求时发送的。然后，ECU设备根据密钥确认质询、功能秘密密钥和第二预定义算法生成密钥确认响应；并将密钥确认响应发送到网关。
结合图图6c，上述密钥确认过程可以是如下的质询响应：
1)GW向对应的ECU发送一个“随机数”作为质询；
2)ECU使用生成的密钥(生成的FSK)和诸如MACVSK(FSK|random)形式的加密函数做出响应，并将其回复给GW，其中MAC表示消息认证码算法，其可以根据实际需要改变为其他合适的算法，在此不做限定；
3)GW将其与自己的一代进行比较，并确定失败还是成功。
在一种可能的实现中，每次供应工具尝试访问车辆时，GW不必完全验证访问令牌。它可以用与计算机文件(cookie)或缓存类似的方法保留和使用的最近的认证日志，以降低延迟。例如，GW可以简单地检查访问令牌中的授权值，而不会浪费时间来验证签名(通过将其与先前验证的签名进行比较)。关于认证过程的细节可以在后面部分中解释。
如图6c所示，首先串联地供应ECU1和ECU2，在另一种可能的情况下，如果网络和GW能够负担得起，则供应工具可以同时访问多个设备。签名验证是最耗时的过程之一。传输、解密和密钥生成速度要更快一些。在设备的验证处理期间，供应工具可以访问其他设备以减少整体时间。访问不同隔离网络上的其他设备有助于通过减少中断机会来优化整个过程。
图9a和图9b示出了根据本公开实施例的在密钥供应方法中基于令牌的认证的流程示意图。这些图实际上规定了前述步骤S602。应当注意，如前所述，供应可以直接在ECU设备上进行(图6c)，或者可以在网关上进行(图6b)，因此，基于具体情况，基于令牌的认证可以在ECU设备和配备有供应工具的第二设备之间进行，或者在网关和第二设备之间进行。在下文中，以其中在网关和供应工具之间进行授权的示例进行描述。对于授权是在ECU设备和配备有供应工具的第二设备之间的情况，对于ECU设备的操作，可以参考网关的操作。
图9a示出了基于令牌的认证的示例性流程图。整个认证过程基于UDS(unifieddiagnostic services，统一诊断服务)认证的汽车标准协议，称为UDS安全访问、种子密钥认证或质询响应认证。与传统的使用随机质询的方式不同，ECU设备使用固定的质询号和“计数器”，如图9b所示。此计数器代表供应的某些特定状态，例如，计数器编号“1”表示该设备目前具有PVK，可以继续执行进一步的步骤来生成VSK。每次设备完成供应后，计数器编号都会增加一。请注意，此计数器永远不能减少，也不能返回较小的数字。当从ECU设备或网关接收到作为质询的计数器时，供应工具应响应与此计数器质询号匹配的访问令牌。由于在成功完成供应后计数器会增加编号，因此供应工具无法再次重用令牌。因此，如果有人尝试使用先前使用的令牌进行中继攻击，则它必须被拒绝，因为它与已经增加的计数器编号不匹配。
将结合图9b进一步描述该过程。
S901：网关向供应工具发送认证请求，以验证供应工具的权限，供应工具从网关接收认证请求。
基于令牌的认证可以是质询响应认证。与传统的使用随机质询的方式不同，ECU设备使用带有“计数器”的固定质询号，如图9a所示。
在一个可能的实现中，认证请求可以包括本地计数器(如图2b所示的计数器)，本地计数器可以用于反映网关的供应状态，一旦网关的供应状态发生变化，计数器的值就会根据网关的预设规则发生变化。
在此，我们可以为本地计数器的值定义特定含义，以阻止恶性访问。例如，如在图9a中的表格中所示，本地计数器为0可表示未供应状态，本地计数器为1可表示已供应PVK的状态，本地计数器为2可表示已供应VSK的状态，本地计数器如果值为3可以表示已供应FSK的状态，以及本地计数器大于3可能表示已更新某些密钥的状态。在下文中，将基于这样的假设进行描述，但是，应当理解，本地计数器的具体值仅用于说明目的，并且不应被解释为对本公开的限制。只要它们指示ECU设备的不同供应状态，其他值也是可能的。
S902：供应工具确定与认证请求匹配的访问令牌。
供应工具根据认证请求确定网关的供应状态，并在确定网关未生成网关的组密钥(VSK)时，将与该组密钥对应的访问令牌用作与认证请求匹配的访问令牌。在此，访问令牌可以由供应工具根据图4a所示的流程从服务器接收。如果供应工具没有正确的访问令牌，则它可以请求服务器更新其访问令牌。稍后将详细描述更新过程。
S903：供应工具向网关发送与认证请求匹配的访问令牌，网关接收与认证请求匹配的访问令牌。
S904：网关确定接收到的访问令牌是否有效。
可以基于访问令牌的特定结构来确定访问令牌的有效性。
图10示出了访问令牌的示例性结构。如图10所示，访问令牌可以包括基于第一预定义算法生成的待验证凭证、待验证计数器、待验证时间戳、待验证车辆标识和待验证签名。
根据该结构，网关在接收到访问令牌后，可以确定所接收的访问令牌是否有效，具体地，网关可以将访问令牌中的每个字段与图2b的ECU设备中所示的本地数据进行比较。如果满足条件，则网关可以确定接收到的访问令牌无效，该条件可以包括以下任意一项或多项：
1)基于本地计数器(图2b的ECU设备中所示的计数器)和第一预定义算法生成的本地凭证与待验证凭证不一致。
服务器根据预定义的算法生成接收到的访问令牌中的凭证，网关可以根据相同的算法生成凭证，以完成验证。
在一种可能的实现中，可以在两侧(网关和服务器)上生成凭证：凭证＝MACKey(附加字符串|计数器|平板)，其中凭证是基于计数器和预共享密钥使用MAC(messageauthentication code，消息认证代码)算法生成的标签；预共享密钥可以是PVK或功能密钥之一，例如认证密钥(Authentication key，AUK)，如果Counter＝1或2，则密钥等于PVK；如果Counter>2，则等于AUK；上述算法中的附加字符串是可选的，例如可以是OEM ID、车辆类型或一些预定义的随机字符串；填充取决于生成凭证的算法，例如拟合32字节和64字节的长度或零。
2)本地计数器(图2b的ECU设备中所示的计数器)与要验证的计数器不一致。
网关可以将本地计数器与接收到的访问令牌中的待验证计数器进行比较，如果这两个值不一致，则确定访问令牌无效。
此外，如先前参考图9a所述，对于正常情况(对于供应工具)，即在配置了PVK并且准备好生成VSK的状态下，计数器必须等于1。
3)本地时间戳晚于待验证时间戳。
网关可以将本地时间戳(图2b的ECU设备中所示的时间戳)与接收到的访问令牌中待验证时间戳进行比较，如果这两个值不一致，则确定访问令牌无效。
实际上，待验证时间戳表示生成访问令牌时的值，本地时间戳表示在制造中(工厂)注入的值，即ECU生产时间，因此，本地时间戳可用于保护供应工具尝试重用旧的(过期/过时)令牌的“重放攻击”情况，因为令牌生成时间应该比ECU生产时间更近。
4)第一设备所属的车辆的标识与待验证车辆的标识不一致。
如前所述，在供应工具的配置阶段，服务器可以向供应工具返回用于访问某些车辆的访问令牌，因此，访问令牌可以包括第一设备所属的车辆的标识，或者，在访问令牌中可能至少有一个待验证车辆标识，这可能是当供应工具向服务器发送的令牌请求(图4a中的步骤S402)包括车辆标识列表时的情况，因此，访问令牌可以包括供应工具被授权访问的车辆的多个标识。
换句话说，时间戳取决于KMS服务器生成的令牌的时间，并且用于检查接收到的访问令牌的到期时间(令牌的新鲜度)。
5)用公钥检查待验证签名失败。
待验证的签名是使用KMS的私钥(与目标设备拥有的公钥配对)和某种签名算法(例如RSASSA-PSS、ECDSA和EdDSA)在上面列出的先前数据{credential,counter,accessible targets,timestamp}上生成的。
在可能的实现中，访问令牌可以包括用于进一步标识可访问车辆和ECU的字段，例如车辆组/类型、设备类型和设备标识列表。
在确定接收到的访问令牌有效时，网关将肯定的访问响应发送到供应工具；在确定接收到的访问令牌无效时，网关向供应工具发送否定访问响应。
图11示出了用于ECU设备的认证逻辑。网关上的认证逻辑与ECU设备上的认证逻辑相似，为简洁起见将省略。当设备收到访问令牌时，它首先验证凭证和计数器是否有效，然后依次验证可访问目标、时间戳和签名是否有效。每次验证失败，尝试次数都会增加，并且如果次数超过三次(可以根据实际需要定义)，则访问可能会受限一定时间(10s)。即使我们指定了有关尝试次数和延迟计时器的阈值，也可以根据汽车制造商的政策对其进行调整。如果整个密钥供应过程成功完成，则设备将擦除KDF和密钥元数据。
以上过程示出了用于生成组密钥即VSK的基于令牌的认证。
如步骤902中所述，通常，由于尚未供应ECU设备，因此ECU设备处的本地计数器等于1，这意味着PVK(即，图2中所示的供应密钥)已经为ECU设备进行了配置，换句话说，ECU设备的配置已经完成，例如基于图3a所示的流程，此时，ECU设备准备好产生组密钥(VSK)。因此，供应工具可以确定网关已准备好供应，并因此确定从KMS服务器接收的访问令牌，以生成VSK作为与认证请求匹配的访问令牌。
在另一种情况下，当质询等于2时，供应工具将基于认证请求确定已为网关供应了VSK，在这种情况下，如果网关仍要在网关上进行供应，则它将结合图10所示的访问令牌的结构，将不得不使用与FSK对应的访问令牌来访问网关。访问令牌中的待验证计数器应等于2，以确保在基于令牌的认证过程中网关或ECU设备的有效性检查。
在另一种情况下，当质询等于3时，供应工具将基于认证请求确定已为网关供应了VSK，在这种情况下，如果网关仍要在网关上进行供应，则它将结合图10所示的访问令牌的结构，将不得不使用与密钥更新对应的访问令牌来访问网关。要验证的计数器应该等于3，以确保在基于令牌的认证期间在网关或ECU设备处进行有效性检查。
在图9b中，我们仅描述了尚未为网关供应VSK的情况，因此，供应工具将使用与组密钥对应的访问令牌来响应质询。在一种可能的实现中，即使当供应工具使用与认证请求匹配的访问令牌访问网关或ECU设备时，网关或ECU设备仍可能拒绝，这实际上考虑了供应工具的安全性，例如，某些攻击可以重用以前使用的令牌、过期的令牌或未经授权的令牌。
无论如何，如果供应工具没有与认证请求匹配的正确的访问令牌，则它可能需要更新其访问令牌。图12示出了用于由供应工具验证认证和授权的可能过程，其中当从网关接收到否定响应时，供应工具可以验证访问令牌并更新访问令牌。
具体地，如图12所示，当供应工具接收访问令牌时，它可以向网关发送UDS认证请求，并接收包括计数器的质询，然后供应工具可以确定与该计数器匹配的访问令牌：
如果没有与该计数器匹配的访问令牌，则供应工具可以向KMS服务器发送令牌更新请求以请求更新的访问令牌，KMS服务器可以根据自己的策略确定供应工具是否被授权供应网关。如果是，则KMS服务器可以将更新的令牌发送到供应工具；和
如果存在与计数器匹配的访问令牌，则供应工具可以将确定的访问令牌发送到网关，并且如果访问令牌在网关的有效性检查中失败，即，访问令牌被网关拒绝，在收到来自网关的否定响应时，供应工具可能会检查以下一项是否失败：访问目标检查、时间戳检查或签名检查。访问目标检查的失败可能导致访问令牌对目标车辆的访问请求的检查；如前所述，时间戳检查失败可能导致令牌更新请求的发送；并且签名的失败可能导致验证密钥ID请求的发送，并且网关可能向供应工具发送验证密钥ID以进行检查，因此将在向KMS服务器的令牌更新请求中使用验证密钥ID。
可能会担心供应商可能会泄漏供应密钥。攻击者想要获得VSK，他/她应至少收集三种在不同部分和阶段管理的信息：
1)供应密钥：在供应商生产时分发给供应商制造/供应工具。
2)预定义的字符串(例如，可以是图7b中所示的salt，用于其他后续秘密密钥的密钥派生)：在供应商生产之前分发给供应商安全经理。
3)加密的RS和TS：在车辆生产时分发给OEM制造/供应工具。
因此，如果VSK暴露在攻击者面前，则意味着信息已从所有供应商制造系统、供应商安全经理和OEM制造系统泄漏。或者，ECU设备(例如HSM)的受保护内存受到损害。
本公开的安全性得到了保证，原因如下：在对每个组件的安全性管理和系统与供应工具之间具有安全通道的假设下，经销商供应工具只能访问在获得OEM(不适用于车辆制造阶段)许可的情况下运输或销售的特定车辆上的某些设备。下一部分将介绍此类售后供应工具的用例。
本公开的技术方案可以提供若干技术优势。
首先，它将便于管理并且易于扩展。例如，供应工具不需要获得每个ECU的访问授权，它们仅从指定可访问目标的服务器获一个访问令牌；此外，供应工具和KMS服务器仅管理一个消息(即，从供应工具到ECU设备的第一供应消息和从KMS服务器到供应工具的第二供应消息，这两个供应消息都包含供应数据)用于车辆上的所有ECU。此外，该技术解决方案可以通过标准汽车协议(例如UDS)部署。
其次，基于提出的解决方案，它可以高效地进行具有流量小和运行速度快的大规模生产。供应商只需要为ECU类型保密(无需以不同方式管理每个ECU)，OEM制造商仅保留一条针对车辆类型的供应消息。由于在ECU设备或网关上自动生成了密钥，因此减少了具有有限信息的数据大小，并且还可以同时为多个设备设置密钥。
第三，提出的解决方案还涉及安全问题。事实上，任何秘密都不会与其他外部系统和工具共享，因此，所提出的解决方案不仅提供了车辆设备与KMS服务器之间的端到端安全性，而且还提供了每辆车的密钥独立性以及来自KMS签名的密钥认证。此外，由于PVK的使用和暴露非常有限，它对密码分析攻击具有鲁棒性。
除了前述解决方案之外，本公开还提供了针对经销商供应工具的解决方案。如图13和图14所示，它们示出了经销商供应工具(售后工具，这里的供应工具也可以实现为软件或硬件)的一些用例。图13所示的第一种情况是用于部件更换(例如ECU更换)。图14所示的第二种情况是用于FCK的更新。大多数过程与上述相同。
如图13所示，为了使那些测试人员能够访问新的替换设备，他们必须从OEM获得所需设备的访问令牌。供应工具在接收到访问令牌后，根据VIN(车辆标识)和新ECU替换的ECU标识(第一设备的替代设备)向服务器发送访问令牌和供应数据的请求，指定用于访问目标车辆(由VIN进行标识)和目标ECU设备(由ECU标识进行标识)和供应数据，供应工具随后可将接收到的访问令牌和供应数据供应给ECU替换，具体操作可以与图5所示的第一设备的供应相同。替换ECU设备可以在ECU设备损坏或旧的情况下应用，测试人员可以使用建议的方法来提供新的ECU设备，并用新的ECU设备替换损坏的或旧的ECU设备。
同样，如果测试人员想要更新某些特定的密钥，则应获得OEM许可的特殊访问令牌以进行更新授权，因为该设备将呈现更高的计数器编号(例如，大于2)。具体地，第二设备可以向服务器发送请求，以请求用于更新第一设备的功能秘密密钥的功能秘密访问令牌，在服务器接收到该请求时，可以将功能秘密访问令牌和相应的更新数据返回给第二设备，当从服务器接收到功能秘密访问令牌和相应的更新数据时，第二设备可以以类似图9中的功能秘密密钥的供应方式来供应第一设备。例如，如图14所示，其描绘了更新车辆中的ECU设备的密钥的过程，对于特定的密钥更新，供应工具可以对ECU设备执行质询响应授权，然后从服务器请求与质询中的计数器编号对应的访问令牌，然后使用访问令牌和服务器返回的更新数据，启用供应工具以更新ECU设备中的密钥。对于令牌更新的细节，可以参考图12和相关描述。
图15示出了根据本公开实施例的第一设备的结构示意图。第一设备可以被安装在车辆中。第一设备1500包括：接收模块1501、确定模块1502、发送模块1503和生成模块1504。
接收模块1501用于从第二设备接收请求访问第一设备的访问请求；确定模块1502用于根据访问请求确定第二设备是否被允许访问第一设备；发送模块1503用于根据确定向第二设备发送访问响应。接收模块1501还用于从第二设备接收第一供应消息，其中，第一供应消息包括用于生成组密钥的供应数据，且该组密钥在车内第一设备间共享；生成模块1504用于根据供应数据生成组密钥。
在一种可能的实现中，确定模块1502具体用于在触发接入请求时，向第二设备发送用于验证第二设备权限的认证请求；从第二设备接收与认证请求匹配的接入令牌；确定接收到的接入令牌是否有效；
发送模块1503用于在确定接收到的访问令牌有效时，向第二设备发送肯定的访问响应；并在确定接收到的访问令牌无效时，向第二设备发送否定访问响应。
在一种可能的实现中，第一设备还包括：获取模块，用于从服务器获取本地供应数据，其中，本地供应数据包括供应密钥、公钥和本地时间戳，供应密钥用于生成组密钥，公钥用于验证第二设备的权限，本地时间戳用于验证生成的供应密钥的有效性。
在一种可能的实现中，供应数据包括：由供应密钥加密的随机字符串、由供应密钥加密的供应时间戳和验证签名；
生成模块1504用于：通过使用供给密钥对供应数据进行解密以获取随机字符串和供给时间戳；根据随机字符串和供给时间戳生成组密钥；根据验证签名验证生成的供应密钥的有效性。
在一种可能的实现中，访问令牌包括：基于第一预定义算法生成的待验证凭证、待验证计数器、待验证时间戳、至少一个待验证车辆标识和待验证签名；
确定模块1502具体用于：
如果满足条件，则确定接收到的访问令牌无效，其中条件包括以下任意一项或多项：基于本地计数器生成的本地凭证和第一预定义算法与待验证凭证不一致，本地计数器与待验证计数器不一致，本地时间戳晚于待验证时间戳，第一设备所属车辆的标识与至少一个待验证的车辆标识不一致，无法通过公钥检查待验证签名。
在一种可能的实现中，访问令牌包括以下任何一个或多个：车辆类型、设备类型和设备标识列表。
在一种可能的实现中，认证请求包括本地计数器，本地计数器用于反映第一设备的供应状态，并且一旦设备的供应状态改变，则计数器的值基于第一设备的预设规则而改变。
在一种可能的实现中，发送模块1503还用于：向第二设备发送第一供应响应。
在一种可能的实现中，接收模块1501还用于，从第二设备接收用于为第一设备供应功能秘密密钥的供应请求；生成模块1504还用于根据组密钥和预先存储的数据，生成功能秘密密钥；发送模块1503还用于向第二设备发送第二供应响应。
在一种可能的实现中，接收模块1501还用于从第三设备接收密钥确认质询，其中，密钥确认质询是第三设备在从第二设备接收到密钥确认请求后发送的，用于确认功能秘密密钥是否正确生成；生成模块1504还用于根据密钥确认质询、功能秘密密钥和第二预定义算法，生成密钥确认响应；发送模块1503还用于向第三设备发送密钥确认响应。
根据本公开提供的解决方案，可以借助于包含供应数据的一个供应消息来向车辆中的所有ECU设备供应组密钥。这样，提高了密钥供应的效率，并且降低了供应成本。通过使用生成的组密钥，确保了与ECU设备关联的数据通信的安全性。此外，由于在ECU设备上自动生成了密钥，因此减少了有限信息下的数据大小，还可以同时为多个设备设置密钥。
第一设备可以应用于实现上述方法实施例中的任何一个中的技术方案。其实现原理和技术效果类似，此处不再赘述。
图16示出了根据本公开实施例的第二设备的结构示意图。第二设备1600包括发送模块1601和接收模块1602。
发送模块1601用于向第一设备发送用于请求访问第一设备的访问请求，第一设备安装在车辆中；接收模块1602用于接收第一设备的访问响应，其中，访问响应由第一设备根据访问请求返回；发送模块1601还用于向第一设备发送第一供应消息，其中，第一供应消息包括用于由第一设备生成组密钥的供应数据，组密钥在车辆中的第一设备之间共享。
在一种可能的实现中，发送模块1601还用于向服务器发送请求与组密钥对应的访问令牌的令牌请求，其中，该令牌请求包括第二设备计划供应的车辆的一个或多个标识。车辆中包括第一设备所属的车辆；接收模块1602还用于从服务器接收与组密钥对应的访问令牌和与访问令牌相对应的第二供应消息。
在一种可能的实现中，接收模块1602还用于从第一设备接收用于验证第二设备的权限的认证请求；
第二设备还包括确定模块，该确定模块还用于确定与认证请求匹配的访问令牌；发送模块1601还用于向第一设备发送与认证请求匹配的访问令牌。
在一种可能的实现中，确定模块还用于根据认证请求，确定第一设备的供应状态；在确定第一设备未生成第一设备的组密钥时，使用该组密钥对应的访问令牌作为与认证请求匹配的访问令牌。
在一种可能的实现中，接收模块1602还用于从第一设备接收否定的访问响应，其中，访问响应由第一设备基于访问请求返回；发送模块1601还用于向服务器发送令牌更新请求，用于更新第一设备的访问令牌，并从服务器接收更新后的访问令牌作为与组密钥对应的访问令牌。
在一种可能的实现中，接收模块1602还用于从第一设备接收第一供应响应；
发送模块1601还用于：当第一供应响应指示第一设备成功生成了组密钥时，发送用于为第一设备供应功能秘密密钥的供应请求；和
接收模块1602还用于从第一设备接收第二供应响应。
在一种可能的实现中，发送模块1601还用于，向服务器发送为第一设备的替换设备请求访问令牌的请求；接收模块1602，还用于从服务器接收与组密钥对应的访问令牌；并使用收到的访问令牌供应替换设备。
根据本公开，使第二设备能够访问车辆中的第一设备并利用一个供应消息为车辆中的所有第一设备配置组密钥，从而降低流量开销、减少网络传输和降低运行延迟，即使是针对很多设备和很多车辆进行部署。
可以应用第二设备以实现上述方法实施例中的任何一个中的技术方案。其实现原理和技术效果类似，此处不再赘述。
图17示出了根据本公开实施例的服务器的结构示意图。服务器1700包括接收模块1701和发送模块1702。
接收模块1701用于从第四设备接收用于配置第一设备的配置请求，其中，配置请求包括第一设备所属的车辆的标识，第一设备安装在车辆中；发送模块1702用于向第四设备发送本地供应数据，其中，该本地供应数据用于生成第一设备的组密钥，该组密钥在车辆的第一设备之间共享。
在一种可能的实现中，接收模块1701还用于从第二设备接收令牌请求，其中，令牌请求中包括第二设备计划供应的车辆的一个或多个标识，以及第一设备所属的车辆的标识包括在车辆中；发送模块1702还用于向第二设备发送令牌请求对应的访问令牌和访问令牌对应的第二供应消息。
在一种可能的实现中，接收模块1701还用于从第二设备接收用于更新第一设备的访问令牌的令牌更新请求，并根据令牌更新请求，向第二设备发送更新后的访问令牌。
该服务器可以用于实现上述方法实施例中的任何一个中的技术方案。其实现原理和技术效果类似，此处不再赘述。
图18是根据本公开实施例的第一设备的示意性框图。
如图18所示，本公开的实施例还提供了第一设备1800。设备1800可以是图15中的设备1500，其可以用于实现与方法实施例中的方法相对应的与第一设备有关的内容。设备1800包括输入接口1810、输出接口1820、处理器1830和存储器1840。输入接口1810、输出接口1820、处理器1830和存储器1840可以通过总线系统连接。存储器1840用于存储程序、指令或代码。处理器1830用于执行存储器1840中的程序、指令或代码以控制输入接口1810接收信号并控制输出接口1820发送信号并完成前述方法实施例中的操作。
在一个具体的实现中，图15所示的设备1500中的发送模块1503可以利用图18中的输出接口1820来实现，同样，接收模块1501可以用图18中的输入接口1810来实现。在图15所示的设备1500中的确定模块1502和生成模块1504可以用图18中的处理器1830来实现。
图19是根据本公开实施例的第二设备的示意性框图。
如图19所示，本公开的实施例还提供了第一用户设备1900。设备1900可以是图16中的设备1600，其可以用于实现与方法实施例中的方法相对应的与第一设备有关的内容。设备1900包括输入接口1910、输出接口1920、处理器1930和存储器1940。输入接口1910、输出接口1920、处理器1930和存储器1940可以通过总线系统连接。存储器1940用于存储程序、指令或代码。处理器1930用于执行存储器1940中的程序、指令或代码以控制输入接口1910接收信号并控制输出接口1920发送信号并完成前述方法实施例中的操作。
在一个具体的实现中，图16所示的设备1600中的发送模块1601可以利用图19中的输出接口1920来实现，同样，接收模块1602可以利用图19中的输入接口1910来实现。
图20是根据本公开实施例的服务器的示意性框图。
如图20所示，本公开的实施例还提供了第一用户设备2000。设备2000可以是图17中的设备1700，其可以用于实现与方法实施例中的方法相对应的与第一设备有关的内容。设备2000包括输入接口2010、输出接口2020、处理器2030和存储器2040。输入接口810、输出接口2020、处理器2030和存储器2040可以通过总线系统连接。存储器2040用于存储程序、指令或代码。处理器2030用于执行存储器2040中的程序、指令或代码以控制输入接口2010接收信号并控制输出接口2020发送信号并完成前述方法实施例中的操作。
在一个具体的实现中，图17所示的设备1700中的发送模块1702可以利用图20中的输出接口2020来实现，同样，接收模块1701可以用图20中的输入接口2010来实现。
本公开还提供了一种存储计算机可执行指令的计算机存储介质，该计算机可执行指令在被执行时实现根据本公开实施例的方法。
提供了本公开还提供了一种计算机程序产品，包括指令，当在计算机上执行该指令时，该指令使计算机执行上述实施例中的方法。
例如，可以理解的是，与所描述的方法相关的公开对于用于执行该方法的相应设备或系统也可以成立，反之亦然。例如，如果描述了一个或多个具体方法步骤，则相应的设备可以包括一个或多个单元，例如功能单元，以执行所述的一个或多个方法步骤(例如，一个单元执行一个或多个步骤，或多个单元各自执行多个步骤中的一个或多个)，尽管这样的一个或多个单元没有在图中明确描述或说明。另一方面，例如，如果基于一个或多个单元(例如功能单元)来描述特定装置，则相应的方法可以包括执行一个或多个单元的功能的一个步骤(例如，执行一个或多个单元的功能的一个步骤，或各自执行一个或多个单元的功能的多个步骤)，即使该一个或多个步骤在图中没有明确描述或图示。此外，可以理解的是，除非另有特别说明，本文描述的各种示例性实施例和/或方面的特征可以相互组合。
本公开的说明书和权利要求书以及上述图中的术语，如“第一”、“第二”，是为了区分不同的对象，但不是为了定义特定的顺序。
在本公开的实施例中，诸如“和/或”的术语仅仅用于描述关联对象之间的关联，其表示可能存在三种关系，例如，A和/或B可以表示仅存在A，同时存在A和B，以及仅存在B。
在本公开的实施例中，诸如“示例地”或“例如”的表达方式用于表示对示例或实例进行说明。在本公开的实施例中，任何被描述为“示例地”或“例如”的实施例或设计方案不应被解释为是较于其他实施例或设计方案的优选或较于其他实施例或设计方案具有优势。具体地，使用“示例地”或“例如”旨在以特定方式呈现相关概念。
在一个或多个示例中，所述功能可在硬件、软件、固件或其任意组合中实现。如果以软件实现，则功能可以作为一个或多个指令或代码存储在计算机可读介质上或进行传输并由基于硬件的处理单元执行。计算机可读介质可以包括计算机可读存储介质，其对应于有形介质，例如数据存储介质或通信介质，其包括便于，例如，根据通信协议，将计算机程序从一个地方传输到另一个地方的任何介质。以这种方式，计算机可读介质一般可以对应于(1)有形的计算机可读存储介质，它是非暂时性的，或者(2)通信介质，例如信号或载波。数据存储介质可以是可由一个或多个计算机或一个或多个处理器访问的任何可用介质，以检索用于实施本公开所述技术的指令、代码和/或数据结构。计算机程序产品可以包括计算机可读介质。
通过举例，而非限制，这样的计算机可读存储介质可以包括RAM、ROM、EEPROM、CD-ROM或其他光盘存储、磁盘存储或其他磁性存储设备、闪存或任何其他介质，这些介质可以用于存储以指令或数据结构形式存在的所需程序代码，并且可以由计算机访问。另外，任何连接都被适当地称为计算机可读介质。例如，如果使用同轴电缆、光纤电缆、双绞线、数字用户线(Digital subscriber line，DSL)或诸如红外、无线电和微波的无线技术从网站、服务器或其他远程源传输指令，那么同轴电缆、光纤电缆、双绞线、DSL或诸如红外、无线电和微波的无线技术被包括在介质的定义中。然而，应该理解的是，计算机可读存储介质和数据存储介质不包括连接、载波、信号或其它暂时性介质，而是针对非暂时性的有形存储介质。本文所用的磁盘和光盘包括光盘(Compact disc，CD)、激光光盘、光学光盘、数字多功能光盘(digital versatile disc，DVD)、软盘和蓝光光盘，其中磁盘通常用磁力再现数据，而光盘则用激光光学再现数据。上述的组合也应包括在计算机可读介质的范围内。
指令可以由一个或多个处理器执行，例如一个或多个数字信号处理器(digitalsignal processor，DSP)、通用微处理器、特定应用集成电路(application specificintegrated circuit，ASIC)、现场可编程逻辑阵列(field programmable logic array，FPGA)或其他等效的集成或离散逻辑电路。因此，本文使用的术语"处理器"可以指任何上述结构或适合于实现本文所述技术的任何其它结构。此外，在某些方面，本文所述的功能可以在配置为编码和解码的专用硬件和/或软件模块内提供，或者并入组合编解码器中。此外，这些技术可以在一个或多个电路或逻辑元件中完全实现。
本公开的技术可以在多种设备或设备中实现，包括无线手机、集成电路(integrated circuit，IC)或一组IC(例如，芯片组)。在本公开中描述了各种组件、模块或单元，以强调配置为执行所公开的技术的设备的功能方面，但不一定需要由不同的硬件单元实现。相反，如上所述，各种单元可以结合在编解码器硬件单元中，或者由互操作硬件单元的集合提供，包括如上所述的一个或多个处理器，与合适的软件和/或固件结合。
计算机可读非暂时性介质包括所有类型的计算机可读介质，包括磁性存储介质、光学存储介质和固态存储介质，特别是不包括信号。应当理解的是，该软件可以安装在路由器、客户端或其他网络设备中并与之一起销售。可选地，软件可以被获取并加载到设备中，包括通过光盘介质或从任何方式的网络或分配系统中获取软件，例如，从软件创建者拥有的服务器或从不拥有但由软件创建者使用的服务器中获取。例如，该软件可以存储在服务器上以便通过互联网分发。
在权利要求中，“包括”一词不排除其他元素或步骤，不定冠词“一个(a)”或“一个(an)”不排除多个。一个处理器或其他单元可以实现权利要求书中所叙述的几个项目的功能。仅仅是某些措施在相互不同的从属权利要求中被叙述，并不表明、排除或暗示利用这些措施的组合获得好处。计算机程序可以存储或分发在合适的介质上，例如与其它硬件一起提供的光存储介质或固态介质，或作为其它硬件的一部分，但也可以以其它形式(例如，通过因特网或其它有线或无线电信系统)分发。
前述详细描述已被提出，用于说明和描述的目的。它并意图为详尽的，也不意图将本文所要求的主题事项限制在所公开的精确形式中。根据上述教导，许多修改和变化是可能的。选择所描述的实施例是为了最好地解释所公开的技术的原理及其实际应用，从而使本技术领域的其他技术人员能够在各种实施例中最好地利用该技术并进行各种修改，这些修改适合于所设想的特定用途。旨在通过所附的权利要求书来限定本公开的范围。

Claims (28)

1.一种密钥供应方法，由第一设备实现，其中，所述第一设备安装在车辆中，所述方法包括：
从第二设备接收用于请求访问所述第一设备的访问请求；
基于所述访问请求确定所述第二设备是否被允许访问所述第一设备；
基于所述确定向所述第二设备发送访问响应；
从所述第二设备接收第一供应消息，其中，所述第一供应消息包括用于生成组密钥的供应数据，并且所述组密钥在所述车辆中的第一设备之间共享；以及
根据所述供应数据生成所述组密钥。
2.根据权利要求1所述的方法，其中，所述基于所述访问请求确定所述第二设备是否被允许访问所述第一设备包括：
当触发所述访问请求时，向所述第二设备发送用于验证所述第二设备的权限的认证请求；
从所述第二设备接收与所述认证请求匹配的访问令牌；
确定所述接收到的所述访问令牌是否有效；
其中，所述基于所述确定向所述第二设备发送所述访问响应包括：
当确定所述接收到的所述访问令牌有效时，向所述第二设备发送肯定访问响应；以及
当确定所述接收到的所述访问令牌无效时，向所述第二设备发送否定访问响应。
3.根据权利要求1或2所述的方法，其中，在从所述第二设备接收所述访问请求之前，所述方法还包括：
从服务器获取本地供应数据，其中，所述本地供应数据包括供应密钥、公钥和本地时间戳，所述供应密钥用于生成所述组密钥，所述公钥用于验证所述第二设备的权限，并且所述本地时间戳用于验证所生成的供应密钥的有效性。
4.根据权利要求3所述的方法，其中，所述供应数据包括：由所述供应密钥加密的随机字符串、由所述供应密钥加密的供应时间戳和验证签名；
其中，所述根据所述供应数据生成所述组密钥包括：
通过使用所述供应密钥对所述供应数据进行解密，以得到所述随机字符串和所述供应时间戳；
根据所述随机字符串和所述供应时间戳生成所述组密钥；以及
根据所述验证签名，验证所生成的供应密钥的有效性。
5.根据权利要求3或4所述的方法，其中，所述访问令牌包括：基于第一预定义算法生成的待验证凭证、待验证计数器、待验证时间戳、至少一个待验证的车辆标识和待验证签名；
其中，所述确定所述接收到的访问令牌是否有效包括：
如果满足条件，则确定所述接收到的访问令牌无效，其中，所述条件包括以下任一项或多项：基于本地计数器和第一预设算法生成的本地凭证与所述待验证凭证不一致、所述本地计数器与所述待验证计数器不一致、所述本地时间戳晚于所述待验证时间戳、所述第一设备所属的车辆的标识与所述至少一个待验证的车辆标识不一致、无法通过所述公钥检查所述待验证签名。
6.根据权利要求5所述的方法，其中，所述访问令牌包括以下任意一种或多种：车辆类型、设备类型和设备标识列表。
7.根据权利要求5或6所述的方法，其中，所述认证请求包括所述本地计数器、所述本地计数器用于反映所述第一设备的供应状态，并且一旦所述第一设备的所述供应状态改变，所述计数器的值由所述第一设备基于预设规则改变。
8.根据权利要求1-7中任一项所述的方法，还包括：
向所述第二设备发送第一供应响应。
9.根据权利要求8所述的方法，还包括：
从所述第二设备接收用于为所述第一设备供应功能秘密密钥的供应请求；
基于所述组密钥和预先存储数据生成所述功能秘密密钥；以及
向所述第二设备发送第二供应响应。
10.根据权利要求9所述的方法，还包括：
从第三设备接收密钥确认质询，其中，所述密钥确认质询是在从所述第二设备接收到用于确认所述功能秘密密钥是否正确生成的确认请求时由所述第三设备发送的；
根据所述密钥确认质询、所述功能秘密密钥和第二预定义算法，生成密钥确认响应；以及
向所述第三设备发送所述密钥确认响应。
11.一种密钥供应方法，由第二设备实现，包括：
向第一设备发送用于请求访问所述第一设备的访问请求，其中，所述第一设备安装在车辆中；
从所述第一设备接收访问响应，其中，所述第一设备基于所述访问请求返回所述访问响应；以及
向所述第一设备发送第一供应消息，其中，所述第一供应消息包括用于由所述第一设备生成组密钥的供应数据，并且所述组密钥在所述车辆中的第一设备之间共享。
12.根据权利要求11所述的方法，其中，在向所述第一设备发送用于请求访问所述第一设备的访问请求之前，所述方法还包括：
向服务器发送用于请求与所述组密钥对应的访问令牌的令牌请求，其中，所述令牌请求中包括所述第二设备计划供应的一个或多个车辆的标识，所述车辆中包括所述第一设备所属的车辆；以及
从所述服务器接收与所述组密钥对应的访问令牌和与所述访问令牌相对应的第二供应消息。
13.根据权利要求12所述的方法，其中，在从所述第一设备接收所述访问响应之前，所述方法还包括：
从所述第一设备接收用于验证所述第二设备的权限的认证请求；
确定与所述认证请求匹配的访问令牌；以及
向所述第一设备发送所述与认证请求匹配的访问令牌。
14.如权利要求13所述的方法，其中，所述确定与所述认证请求匹配的访问令牌包括：
根据所述认证请求，确定所述第一设备的供应状态；以及
在确定所述第一设备没有生成所述第一设备的所述组密钥时，使用与所述组密钥对应的访问令牌作为与所述认证请求匹配的访问令牌。
15.根据权利要求13或14所述的方法，其中，所述从所述第一设备接收所述访问响应包括：
从所述第一设备接收否定访问响应；
在向所述第一设备发送所述第一供应消息之前，所述方法还包括：
向所述服务器发送令牌更新请求，用于更新所述第一设备的访问令牌；以及从所述服务器接收更新后的访问令牌作为与所述组密钥对应的访问令牌。
16.如权利要求11-15中任一项所述的方法，还包括：
从所述第一设备接收第一供应响应；
当所述第一供应响应指示所述第一设备成功生成了所述组密钥时，发送用于为所述第一设备供应功能秘密密钥的供应请求；以及
从所述第一设备接收第二供应响应。
17.根据权利要求11-16中任一项所述的方法，还包括：
向所述服务器发送用于请求所述第一设备的替换设备的访问令牌的请求；
从所述服务器接收与所述组密钥对应的访问令牌；以及
使用所述接收到的访问令牌来供应所述替换设备。
18.一种密钥供应方法，由服务器实现，包括：
从第四设备接收用于配置第一设备的配置请求，其中，所述配置请求包括所述第一设备所属车辆的标识，且所述第一设备安装在所述车辆中；以及
向所述第四设备发送本地供应数据，其中，所述本地供应数据用于生成所述第一设备的组密钥，并且所述组密钥在所述车辆中的第一设备之间共享。
19.根据权利要求18所述的方法，还包括：
从第二设备接收令牌请求，其中，所述令牌请求包括所述第二设备计划供应的车辆的一个或多个标识，并且所述车辆中包括所述第一设备所属的车辆；以及
向所述第二设备发送与所述令牌请求对应的访问令牌和与所述访问令牌对应的第二供应消息。
20.根据权利要求19所述的方法，还包括：
从所述第二设备接收用于更新所述第一设备的访问令牌的令牌更新请求，并根据所述令牌更新请求向所述第二设备发送更新的访问令牌。
21.一种第一设备，用于执行根据权利要求1-10中任一项所述的方法。
22.一种第二设备，用于执行根据权利要求11-16中任一项所述的方法。
23.一种服务器，用于执行根据权利要求17-19中任一项所述的方法。
24.一种车辆，包括根据权利要求21所述的第一设备。
25.一种第一设备，包括处理器和用于存储能够在所述处理器上运行的计算机程序的存储器，其中，当所述计算机程序运行时，所述处理器用于执行根据权利要求1-10中任一项所述的方法。
26.一种第二设备，包括处理器和用于存储能够在所述处理器上运行的计算机程序的存储器，其中，当所述计算机程序运行时，所述处理器用于执行根据权利要求11-16中任一项所述的方法。
27.一种服务器，包括处理器和用于存储能够在所述处理器上运行的计算机程序的存储器，其中，当所述计算机程序运行时，所述处理器用于执行根据权利要求17-19中任一项所述的方法。
28.一种存储计算机可执行指令的计算机存储介质，所述计算机可执行指令在被执行时实现根据权利要求1-19中任一项所述的方法。
CN202080005150.5A 2020-12-31 2020-12-31 密钥供应方法以及相关产品 Active CN113016201B (zh)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2020/142507 WO2022141574A1 (en) 2020-12-31 2020-12-31 Key provisioning method and related products

Publications (2)

Publication Number Publication Date
CN113016201A true CN113016201A (zh) 2021-06-22
CN113016201B CN113016201B (zh) 2022-05-24

Family

ID=76385272

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202080005150.5A Active CN113016201B (zh) 2020-12-31 2020-12-31 密钥供应方法以及相关产品

Country Status (4)

Country Link
EP (1) EP4260587A4 (zh)
JP (1) JP2024501578A (zh)
CN (1) CN113016201B (zh)
WO (1) WO2022141574A1 (zh)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114124578A (zh) * 2022-01-25 2022-03-01 湖北芯擎科技有限公司 一种通信方法、装置、车辆及存储介质
WO2022121685A1 (en) * 2020-12-09 2022-06-16 International Business Machines Corporation Edge computing autonomous vehicle infrastructure
WO2024036805A1 (zh) * 2022-08-15 2024-02-22 华为技术有限公司 通信方法、装置和系统
CN117793706A (zh) * 2024-02-28 2024-03-29 合肥工业大学 一种车内ecu组通信方法及通信系统

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116471587B (zh) * 2023-04-19 2023-10-20 合肥工业大学 一种v2v通信下的车组内通信密钥生成及更新方法

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101159556A (zh) * 2007-11-09 2008-04-09 清华大学 基于组密钥服务器的共享加密文件系统中的密钥管理方法
CN103096308A (zh) * 2011-11-01 2013-05-08 华为技术有限公司 生成组密钥的方法和相关设备
CN105187376A (zh) * 2015-06-16 2015-12-23 西安电子科技大学 车联网中汽车内部网络的安全通信方法
CN108259465A (zh) * 2017-12-08 2018-07-06 清华大学 一种智能汽车内部网络的认证加密方法
US20180227120A1 (en) * 2015-08-05 2018-08-09 Kddi Corporation Management device, management system, key generation device, key generation system, key management system, vehicle, management method, key generation method, and computer program
US20190207915A1 (en) * 2016-09-23 2019-07-04 Apple Inc. Secure communication of network traffic
US20200213287A1 (en) * 2018-12-27 2020-07-02 Didi Research America, Llc Trusted platform protection in an autonomous vehicle
US20200211301A1 (en) * 2018-12-27 2020-07-02 Didi Research America, Llc Repair management system for autonomous vehicle in a trusted platform

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9215228B1 (en) * 2014-06-17 2015-12-15 Cisco Technology, Inc. Authentication of devices having unequal capabilities
US20200177398A1 (en) * 2016-06-17 2020-06-04 Kddi Corporation System, certification authority, vehicle-mounted computer, vehicle, public key certificate issuance method, and program

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101159556A (zh) * 2007-11-09 2008-04-09 清华大学 基于组密钥服务器的共享加密文件系统中的密钥管理方法
CN103096308A (zh) * 2011-11-01 2013-05-08 华为技术有限公司 生成组密钥的方法和相关设备
CN105187376A (zh) * 2015-06-16 2015-12-23 西安电子科技大学 车联网中汽车内部网络的安全通信方法
US20180227120A1 (en) * 2015-08-05 2018-08-09 Kddi Corporation Management device, management system, key generation device, key generation system, key management system, vehicle, management method, key generation method, and computer program
US20190207915A1 (en) * 2016-09-23 2019-07-04 Apple Inc. Secure communication of network traffic
CN108259465A (zh) * 2017-12-08 2018-07-06 清华大学 一种智能汽车内部网络的认证加密方法
US20200213287A1 (en) * 2018-12-27 2020-07-02 Didi Research America, Llc Trusted platform protection in an autonomous vehicle
US20200211301A1 (en) * 2018-12-27 2020-07-02 Didi Research America, Llc Repair management system for autonomous vehicle in a trusted platform

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2022121685A1 (en) * 2020-12-09 2022-06-16 International Business Machines Corporation Edge computing autonomous vehicle infrastructure
CN114124578A (zh) * 2022-01-25 2022-03-01 湖北芯擎科技有限公司 一种通信方法、装置、车辆及存储介质
WO2024036805A1 (zh) * 2022-08-15 2024-02-22 华为技术有限公司 通信方法、装置和系统
CN117793706A (zh) * 2024-02-28 2024-03-29 合肥工业大学 一种车内ecu组通信方法及通信系统
CN117793706B (zh) * 2024-02-28 2024-05-07 合肥工业大学 一种车内ecu组通信方法及通信系统

Also Published As

Publication number Publication date
EP4260587A4 (en) 2023-12-06
JP2024501578A (ja) 2024-01-12
WO2022141574A1 (en) 2022-07-07
EP4260587A1 (en) 2023-10-18
CN113016201B (zh) 2022-05-24

Similar Documents

Publication Publication Date Title
CN113016201B (zh) 密钥供应方法以及相关产品
JP7280396B2 (ja) 機器の安全なプロビジョニングと管理
US10742409B2 (en) Legitimacy verification of a node in a distributed network
US10382485B2 (en) Blockchain-assisted public key infrastructure for internet of things applications
CN106664311B (zh) 支持异构电子设备之间差异化的安全通信
US10419220B2 (en) Management device, key generating device, vehicle, maintenance tool, management system, management method, and computer program
EP3073668B1 (en) Apparatus and method for authenticating network devices
CN113691560B (zh) 数据传送方法、控制数据使用的方法以及密码设备
EP3850510B1 (en) Infrastructure device enrolment
KR102450811B1 (ko) 차량 내부 네트워크의 키 관리 시스템
JP7440026B2 (ja) 分散化認証方法
CN110708388A (zh) 用于提供安全服务的车身安全锚节点设备、方法以及网络系统
WO2011142353A1 (ja) 通信装置および通信方法
KR20140023799A (ko) Ｃａｎ에서 데이터의 기밀성과 무결성을 보장하는 방법
CN114547583A (zh) 身份认证系统、方法、装置、设备及计算机可读存储介质
CN110120866B (zh) 现场设备的用户管理方法
CN114095919A (zh) 一种基于车联网的证书授权处理方法及相关设备
CN114338091B (zh) 数据传输方法、装置、电子设备及存储介质
CN114915942A (zh) 通信密钥配置方法及装置
US11968302B1 (en) Method and system for pre-shared key (PSK) based secure communications with domain name system (DNS) authenticator
Wei et al. Authenticated can communications using standardized cryptographic techniques
WO2024093684A1 (zh) 通信方法、装置和系统
WO2022178890A1 (zh) 一种密钥的传输方法和装置
Sakon et al. Simple Cryptographic Key Management Scheme of the Electronic Control Unit in the Lifecycle of a Vehicle
CN117155656A (zh) 组网通信方法、装置、设备及存储介质

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant