Secure access methods, devices and vehicles

Abstract

This application provides a secure access method, apparatus, and vehicle. The method includes: receiving a first message sent by a server, the first message indicating at least one service that the server can provide, the first message including a first random number; determining at least one second key based on a first key, a first security policy option, and the first random number, wherein the first key is a symmetric key, the first security policy option indicating the security level corresponding to at least one interface of at least one service in the service, and the at least one second key used to verify a second message sent by the server, the second message including data corresponding to the first service, and the at least one service including the first service. Through this method, different protection strategies and communication keys can be adopted for different interfaces in the SOME / IP service, ensuring secure communication between the server and client while avoiding over-protection or poor processing performance.

Description

Secure access method, device and vehicle TECHNICAL FIELD

[0001] The present application relates to the field of security, and more particularly, to a secure access method, device and vehicle. BACKGROUND

[0002] With the wide use of intelligent vehicles in daily life, the number of internal and external communication services of vehicles is gradually increasing. In this context, the middleware of communication services (SOME / IP protocol) is widely used. The application mode of the SOME / IP protocol is that a client requests a method (Method) or subscribes to an event (Event) corresponding to a service (Service) after receiving an offer message provided by a server. If an unauthorized controller or an untrusted application program calls SOME / IP or an untrusted service provider provides services, there will be a great security risk.

[0003] Different interfaces in the same SOME / IP service instance usually have different security protection requirements. However, the current security protection technology adopts a unified security protection strategy for all interfaces in the SOME / IP service. This "one-size-fits-all" processing method cannot ensure the safe communication of the system while taking into account the system performance, which may result in over-protection of the system security or poor processing performance in some cases.

[0004] SUMMARY

[0005] The present application provides a secure access method, device and vehicle, which can adopt different protection strategies and communication keys for different interfaces in the SOME / IP service, and can ensure the safe communication of the server and the client while avoiding over-protection of the system security or poor processing performance.

[0006] In a first aspect, a secure access method is provided. The method is applied in a first client, and the method comprises: receiving a first message sent by a server, the first message being used to at least indicate services that can be provided by the server, the first message comprising a first random number; determining at least one second key according to a first key, a first security policy option and the first random number, the first key being a symmetric key, the first security policy option being used to indicate a security level corresponding to at least one interface of at least one service in the server, the at least one second key being used to verify a second message sent by the server, the second message comprising data corresponding to a first service, the at least one service in the server comprising the first service.

[0007] In a possible implementation, the service end can be understood as a component that provides services in the vehicle, and the client end can be understood as a component that uses services in the vehicle.

[0008] In a possible implementation, the first key can be a key pre-loaded and stored in the first client end and the service end before the vehicle is manufactured, or the first key can be a key negotiated by the client end and the service end based on a key exchange protocol.

[0009] In a possible implementation, the security level corresponding to the at least one interface can correspond to the security protection policy or the security protection mode corresponding to the at least one interface.

[0010] In the embodiment of the application, the first client end can generate at least one second key according to the first key, the first security policy option and the first random number, and verify the second message based on the at least one second key. In this way, different protection policies and communication keys are taken for different interfaces in the SOME / IP service, which can ensure that the service end and the first client end communicate safely while avoiding the phenomenon of excessive security protection or poor processing performance of the system. In addition, compared with the key derivation process of the asymmetric key, the use of the first key can improve the derivation efficiency of the at least one second key and save the computing resources of the first client end and the service end.

[0011] With reference to the first aspect, in some implementations of the first aspect, the first message further includes a first message authentication code, and before the at least one second key is determined according to the first key, the first security policy option and the first random number, the method further includes: determining a third key according to the first key and the first random number; determining a second message authentication code according to the third key and the first message; and determining that the second message authentication code is consistent with the first message authentication code.

[0012] In a possible implementation, determining that the second message authentication code is consistent with the first message authentication code can be understood as that the numerical values of the first message authentication code and the second message authentication code are the same.

[0013] In a possible implementation, determining that the second message authentication code is consistent with the first message authentication code can be understood as that the integrity verification of the first client end on the first message is passed.

[0014] In the embodiments of this application, when the first message authentication code is included in the first message, the first client can derive a third key based on the first key and the first random number, and obtain a second message authentication code according to the third key, so as to verify the first message based on the second message authentication code and the first message authentication code. In this way, it is beneficial for the first client to quickly confirm whether the first message is tampered with in the transmission process and the source is trustworthy, so as to derive at least one second key in time for communication with the server.

[0015] In combination with the first aspect, in some implementations of the first aspect, the second message is an event message, and the method further includes: sending first subscription information to the server, the first subscription information including a third message authentication code, the third message authentication code being determined based on the third key and the first subscription information, or the third message authentication code being determined based on the at least one second key and the first subscription information; receiving first response information, the first response information being used to indicate that the server accepts the first subscription information.

[0016] In the embodiments of this application, the third message authentication code can be carried in the first subscription information. Since the third message authentication code is determined based on the third key and the first subscription information, or the third message authentication code is determined based on the at least one second key and the first subscription information, the server can verify the first subscription information based on the third message authentication code. In this way, it is beneficial for the server to quickly determine whether the first subscription information is from an expected sender, thereby facilitating the sending of the second message to the first client.

[0017] In combination with the first aspect, in some implementations of the first aspect, the first subscription information further includes a second random number, the second random number being a random number generated after the first client is powered on; the third key is determined according to the first key and the first random number, including: determining the third key according to the first key, the first random number and the second random number; before the first subscription information is sent to the server, the method further includes: determining the third message authentication code according to the third key, the first message and the first subscription information.

[0018] In the embodiments of this application, when the first client derives the third key, the second random number generated after the first client is powered on can be applied. In this way, the security of the derived third key can be higher, and the risk of the third key being cracked by an attacker is reduced. On the other hand, the secure access method can be applied to a scenario where one server corresponds to multiple clients and multiple clients are preconfigured with different keys, thereby expanding the application scope of the secure access method.

[0019] With reference to the first aspect, in some implementations of the first aspect, the first subscription information further includes a value of a first counter, and the value of the first counter is used for uniqueness verification of the first subscription information.

[0020] For example, the first client adds the first counter to the first subscription information when sending the first subscription information to the server. After receiving the first subscription information, the server can extract the value of the first counter and detect whether the value of the first counter is greater than the value of the counter obtained by the server before. If the value of the first counter is greater than the value of the counter obtained by the server before, the uniqueness verification of the first subscription information is passed, otherwise, the uniqueness verification of the first subscription information is failed.

[0021] In the embodiments of the present application, the use of the first counter makes the first subscription information unique, and any attempt to repeatedly send the first subscription information will be identified and rejected by the server in time, thereby reducing the risk of replay attack on the server.

[0022] With reference to the first aspect, in some implementations of the first aspect, the second message is a method type message, and the method further includes: sending first request information to the server, the first request information including: a fourth message authentication code or a first label, the fourth message authentication code being determined based on the third key and the first request information, or the fourth message authentication code being determined based on the at least one second key and the first request information, and the first label being used for confidentiality verification of the first request information.

[0023] In the embodiments of the present application, the first client can carry the fourth message authentication code or the first label in the first request information, which helps the server to perform security verification on the first request information based on the fourth message authentication code or the first label, so as to ensure that the first request information is not tampered or forged in the information transmission process.

[0024] With reference to the first aspect, in some implementations of the first aspect, the first request information further includes a second random number, the second random number being a random number generated after the first client is powered on, and the second random number being used for security verification of the first request information, and the method further includes: receiving second response information sent by the server, the second response information being used to indicate that the server accepts the first request information.

[0025] In the embodiments of the present application, the first client can carry the second random number generated by power-on in the first request information, so that the server can derive the third key based on the second random number, and perform security verification on the first request information based on the third key. In this way, the security of the derived third key is higher, and the risk of the third key being cracked by an attacker is reduced. On the other hand, the secure access method can be applied to a scenario where one server corresponds to multiple clients and the multiple clients are preconfigured with different keys, thereby expanding the scope of application of the secure access method.

[0026] In combination with the first aspect, in some implementations of the first aspect, the first request information further includes a value of a second counter, and the value of the second counter is used for unique verification of the first request information.

[0027] In the embodiments of the present application, the use of the second counter makes the first request information unique, and any attempt to repeatedly send the first request information will be identified and rejected by the server in time, thereby reducing the risk of replay attack on the server.

[0028] In combination with the first aspect, in some implementations of the first aspect, the first message further includes a maximum value of a counter associated with at least one interface message of at least one service in the server, and the maximum value of the counter is used for communication recovery after failure or restart of the first client.

[0029] In the embodiments of the present application, by using the maximum value of the counter, even if the local counter of the first client is lost due to abnormal power-off and other factors, the first client can perform calculation based on the maximum value of the counter as the initial value after being online again, without the need to re-negotiate with the server, so that the first client can better cope with temporary failure.

[0030] In combination with the first aspect, in some implementations of the first aspect, the first message further includes a first timestamp, and before the first key, the first security policy option and the first random number are determined, and before at least one second key is determined, the method further includes determining that a difference between a second timestamp and the first timestamp is less than or equal to a preset threshold, and the second timestamp is used to indicate a time when the first client receives the first message.

[0031] In the embodiments of the present application, the first client can perform unique verification on the first message according to the first timestamp carried in the first message, thereby reducing the risk of replay attack on the first client.

[0032] With reference to the first aspect, in some implementations of the first aspect, before the receiving the first message sent by the service end, the method further includes: receiving a third message sent by the service end, the third message being used to indicate services that can be provided by the service end, the third message including a second security policy option, the second security policy option being used to indicate that no corresponding security level exists for each interface in the services; and sending a fourth message to the service end according to the third message, the fourth message being used to indicate a security level corresponding to at least one interface in the services provided by the service end.

[0033] In the embodiments of the present application, when the second security policy option is carried in the third message sent by the service end, the client (the first client) that needs to provide a secure access mode can negotiate with the service end, and the service end sends the first message carrying the first security policy option. In this way, the differentiated security access requirements of different clients can be met, and the security and flexibility of data transmission between the service end and the client are taken into account.

[0034] With reference to the first aspect, in some implementations of the first aspect, the first security policy option is preconfigured, or the first security policy option is carried in the first message.

[0035] In a possible implementation, the first security policy option is preconfigured, including: the first client and the service end preconfigure the first security policy option to be consistent through a communication detail table or a configuration tool.

[0036] The second aspect provides a secure access method, which is applied to a service end and includes: sending a first message to a first client, the first message being used to at least indicate services that can be provided by the service end, the first message including a first random number; determining at least one second key according to a first key, a first security policy option, and the first random number, the first key being a symmetric key, the first security policy option being used to indicate a security level corresponding to at least one interface in the at least one service, the at least one second key being used to encrypt a second message, the second message including data corresponding to a first service, and the at least one service including the first service.

[0037] In the embodiments of the present application, the server can generate at least one second key according to the first key, the first security policy option and the first random number, and encrypt the second message based on the at least one second key. In this way, different protection policies and communication keys are adopted for different interfaces in the SOME / IP service, which can ensure the secure communication between the server and the client, and avoid the phenomenon of excessive security protection or poor processing performance of the system. In addition, compared with the key derivation process of the asymmetric key, the use of the first key can improve the derivation efficiency of the at least one second key, and save the computing resources of the first client and the server.

[0038] With reference to the second aspect, in some implementations of the second aspect, the first message further includes a first message authentication code, and before the sending of the first message to the first client, the method further includes: determining a third key according to the first key and the first random number; and determining the first message authentication code according to the third key and the first message.

[0039] In the embodiments of the present application, the server can derive a third key based on the first key and the first random number, and obtain a first message authentication code according to the third key, so as to carry the first message authentication code in the first message. In this way, it is beneficial for the first client to confirm whether the first message is tampered in the transmission process and the source is trusted based on the first message authentication code, so as to derive at least one second key for communication with the server in time.

[0040] With reference to the second aspect, in some implementations of the second aspect, the second message is an event type message, and the method further includes: receiving first subscription information sent by the first client, the first subscription information including a third message authentication code, the third message authentication code being determined based on the third key and the first subscription information, or the third message authentication code being determined based on the at least one second key and the first subscription information; verifying the first subscription information according to the third message authentication code and the third key; and in the case that the first subscription information is verified, sending first response information to the first client, the first response information being used to indicate that the server accepts the first subscription information.

[0041] In the embodiments of the present application, the server can verify the first subscription information through the third message authentication code. In this way, it is beneficial for the server to quickly determine whether the first subscription information is from the expected sender, so as to facilitate the server to send the second message to the first client.

[0042] With reference to the second aspect, in some implementations of the second aspect, the first subscription information further includes a second random number, the second random number being a random number generated after the first client is powered on; and determining the third key according to the first key and the first random number includes determining the third key according to the first key, the first random number and the second random number.

[0043] In the embodiments of the present application, when the third key is derived at the server side, the second random number generated after the first client is powered on can be applied, in this way, the security of the derived third key is higher, and the risk of the third key being cracked by an attacker is reduced. On the other hand, the secure access method can be applied to a scenario in which one server side corresponds to multiple clients and the multiple clients are pre-stored with different keys, thereby expanding the scope of the secure access method.

[0044] With reference to the second aspect, in some implementations of the second aspect, the first subscription information further includes a value of a first counter, the value of the first counter being used for unique verification of the first subscription information.

[0045] In the embodiments of the present application, the first subscription information is unique by using the first counter, any attempt to repeatedly send the first subscription information will be identified and rejected by the server side in time, thereby reducing the risk of the server side being attacked by a replay attack.

[0046] With reference to the second aspect, in some implementations of the second aspect, the method further includes encrypting the second message according to the at least one second key, and sending the encrypted second message to multiple clients, the multiple clients including the first client.

[0047] In a possible implementation, the multiple clients pre-store the same first key.

[0048] In the embodiments of the present application, for event type messages, since the keys pre-stored and derived at the server side and the multiple clients are completely the same, the server side can send the encrypted second message through multicast by using the at least one second key to perform one-time encryption, in this way, the server side avoids multiple encryption calculations, thereby saving the calculation overhead.

[0049] With reference to the second aspect, in some implementations of the second aspect, the second message is a method message, and the method further includes: receiving first request information sent by the first client, the first request information including: a fourth message authentication code or a first tag, the fourth message authentication code being determined based on the third key and the first request information, or the fourth message authentication code being determined based on the at least one second key and the first request information, and the first tag being used for confidentiality verification of the first request information.

[0050] In the embodiments of the present application, the server can perform security verification on the first request information based on the fourth message authentication code or the first tag, so that it can be ensured that the first request information is not tampered with or forged in the information transmission process.

[0051] With reference to the second aspect, in some implementations of the second aspect, the first request information includes: the fourth message authentication code and a second random number, the second random number being a random number generated after the first client is powered on; the third key is determined based on the first key and the first random number, including: determining the third key based on the first key, the first random number, and the second random number; the method further includes: verifying the first request information based on the third key and the fourth message authentication code; and in a case where the first request information is verified, sending second response information to the first client, the second response information being used to indicate that the server accepts the first request information.

[0052] In the embodiments of the present application, since the first client carries the second random number generated after being powered on in the first request information, the server can derive the third key based on the second random number and perform security verification on the first request information based on the third key. In this way, the security of the derived third key can be higher, and the risk of the third key being cracked by an attacker can be reduced. On the other hand, the secure access method can be applied to a scenario in which one server corresponds to multiple clients and the multiple clients are preconfigured with different keys, thereby expanding the scope of application of the secure access method.

[0053] With reference to the second aspect, in some implementations of the second aspect, the first request information further includes a value of a second counter, and the value of the second counter is used for uniqueness verification of the first request information.

[0054] In the embodiments of the present application, the use of the second counter makes the first request information unique, and any attempt to repeatedly send the first request information can be identified and rejected by the server in a timely manner, thereby reducing the risk of the server being attacked by a replay attack.

[0055] With reference to the second aspect, in some implementations of the second aspect, the first message further includes a maximum value of a counter associated with at least one interface message of at least one service of the services, and the maximum value of the counter is used for communication recovery after a first client failure or restart.

[0056] In the embodiments of the present application, by using the maximum value of the counter, even if the first client loses the local counter due to abnormal power-off or other factors, the first client can perform calculation based on the maximum value of the counter as an initial value after being online again, without re-negotiation with the server, so that the first client can better cope with temporary failures.

[0057] With reference to the second aspect, in some implementations of the second aspect, the first message further includes a first timestamp, and the first timestamp is used for uniqueness verification of the first message.

[0058] In the embodiments of the present application, the server carries the first timestamp in the first message, so as to facilitate the first client to perform uniqueness verification on the first message, thereby reducing the risk of replay attack on the first client.

[0059] With reference to the second aspect, in some implementations of the second aspect, before the first message is sent to the first client, the method further includes: sending a third message to the first client, the third message being used to indicate services that can be provided by the server, and the third message including a second security policy option, the second security policy option being used to indicate that there is no corresponding security level for each interface in the services; receiving a fourth message sent by the first client, the fourth message being used to indicate a security level corresponding to at least one interface in the services provided by the server; and sending the first message to the first client includes: sending the first message to the first client according to the fourth message.

[0060] In the embodiments of the present application, when the second security policy option is carried in the third message sent by the server, the client (the first client) that needs to be provided with a secure access mode by the server can negotiate with the server, and the server provides the first message carrying the first security policy option. In this way, the differentiated security access requirements of different clients can be met, and the security and flexibility of data transmission between the server and the client are taken into account.

[0061] With reference to the second aspect, in some implementations of the second aspect, the first security policy option is preconfigured, or the first security policy option is carried in the first message.

[0062] In a third aspect, a secure access apparatus is provided, which is applied in a first client, and the apparatus comprises: a transceiver and a processing unit; the transceiver is configured to receive a first message sent by a server, the first message is used to indicate at least one service provided by the server, and the first message comprises a first random number; and the processing unit is configured to determine at least one second key according to a first key, a first security policy option and the first random number, the first key is a symmetric key, the first security policy option is used to indicate a security level corresponding to at least one interface of at least one service in the service, and the at least one second key is used to verify a second message sent by the server, the second message comprises data corresponding to a first service, and the at least one service in the service comprises the first service.

[0063] With reference to the third aspect, in some implementations of the third aspect, the first message further comprises a first message authentication code, and the processing unit is further configured to: determine a third key according to the first key and the first random number; determine a second message authentication code according to the third key and the first message; and determine that the second message authentication code is consistent with the first message authentication code.

[0064] With reference to the third aspect, in some implementations of the third aspect, the second message is an event message, the transceiver is further configured to: send first subscription information to the server, the first subscription information comprises a third message authentication code, the third message authentication code is determined based on the third key and the first subscription information, or the third message authentication code is determined based on the at least one second key and the first subscription information; and receive first response information, the first response information is used to indicate that the server accepts the first subscription information.

[0065] With reference to the third aspect, in some implementations of the third aspect, the first subscription information further comprises a second random number, the second random number is a random number generated after the first client is powered on; the processing unit is specifically configured to determine the third key according to the first key, the first random number and the second random number; and the processing unit is further configured to determine the third message authentication code according to the third key, the first message and the first subscription information.

[0066] With reference to the third aspect, in some implementations of the third aspect, the first subscription information further comprises a value of a first counter, and the value of the first counter is used for unique verification of the first subscription information.

[0067] In some implementations of the third aspect, in combination with the third aspect, the second message is a method class message, and the transceiver is further configured to send first request information to the server, the first request information including a fourth message authentication code or a first label, the fourth message authentication code being determined based on the third key and the first request information, or the fourth message authentication code being determined based on the at least one second key and the first request information, and the first label being used for confidentiality verification of the first request information.

[0068] In some implementations of the third aspect, in combination with the third aspect, the first request information further includes a second random number, the second random number being a random number generated after the first client is powered on, and the second random number being used for security verification of the first request information; and the transceiver is further configured to receive second response information sent by the server, the second response information being used to indicate that the server accepts the first request information.

[0069] In some implementations of the third aspect, in combination with the third aspect, the first request information further includes a value of a second counter, and the value of the second counter being used for uniqueness verification of the first request information.

[0070] In some implementations of the third aspect, in combination with the third aspect, the first message further includes a maximum value of a counter associated with at least one interface message of at least one service in the service, and the maximum value of the counter being used for communication recovery after the first client fails or restarts.

[0071] In some implementations of the third aspect, in combination with the third aspect, the first message further includes a first timestamp, and the processing unit is further configured to determine that a difference between a second timestamp and the first timestamp is less than or equal to a preset threshold, the second timestamp being used to indicate a time at which the first client receives the first message.

[0072] In some implementations of the third aspect, in combination with the third aspect, the transceiver is further configured to receive a third message sent by the server, the third message being used to indicate services that can be provided by the server, and the third message including a second security policy option, the second security policy option being used to indicate that there is no corresponding security level for each interface in the service; and the processing unit is further configured to send a fourth message to the server according to the third message, the fourth message being used to indicate a security level corresponding to at least one interface in the service provided by the server.

[0073] In some implementations of the third aspect, in combination with the third aspect, the first security policy option is preconfigured, or the first security policy option is carried in the first message.

[0074] In a fourth aspect, a secure access apparatus is provided, which is applied to a server, and the apparatus comprises: a transceiver and a processing unit; the transceiver is configured to send a first message to a first client, the first message is used to indicate at least one service provided by the server, and the first message comprises a first random number; and the processing unit is configured to determine at least one second key according to a first key, a first security policy option and the first random number, the first key is a symmetric key, the first security policy option is used for a security level corresponding to at least one interface of the at least one service, and the at least one second key is used for encrypting a second message, the second message comprises data corresponding to a first service, and the at least one service comprises the first service.

[0075] With reference to the fourth aspect, in some implementations of the fourth aspect, the first message further comprises a first message authentication code, and the processing unit is further configured to: determine a third key according to the first key and the first random number; and determine the first message authentication code according to the third key and the first message.

[0076] With reference to the fourth aspect, in some implementations of the fourth aspect, the second message is an event message, the transceiver is further configured to receive first subscription information sent by the first client, the first subscription information comprises a third message authentication code, the third message authentication code is determined based on the third key and the first subscription information, or the third message authentication code is determined based on the at least one second key and the first subscription information; the processing unit is further configured to verify the first subscription information according to the third message authentication code and the third key; and the transceiver is further configured to send first response information to the first client in a case where the first subscription information is verified, the first response information is used to indicate that the server accepts the first subscription information.

[0077] With reference to the fourth aspect, in some implementations of the fourth aspect, the first subscription information further comprises a second random number, the second random number is a random number generated after the first client is powered on; and the processing unit is specifically configured to determine the third key according to the first key, the first random number and the second random number.

[0078] With reference to the fourth aspect, in some implementations of the fourth aspect, the first subscription information further comprises a value of a first counter, and the value of the first counter is used for verifying uniqueness of the first subscription information.

[0079] With reference to the fourth aspect, in some implementations of the fourth aspect, the processing unit is further configured to encrypt the second message according to the at least one second key, and send the encrypted second message to a plurality of clients, the plurality of clients including the first client.

[0080] With reference to the fourth aspect, in some implementations of the fourth aspect, the second message is a method class message, and the transceiver is further configured to receive first request information sent by the first client, the first request information including a fourth message authentication code or a first label, the fourth message authentication code being determined based on the third key and the first request information, or the fourth message authentication code being determined based on the at least one second key and the first request information, and the first label being used for confidentiality verification of the first request information.

[0081] With reference to the fourth aspect, in some implementations of the fourth aspect, the first request information includes the fourth message authentication code and a second random number, the second random number being a random number generated after the first client is powered on; the processing unit is specifically configured to determine the third key according to the first key, the first random number, and the second random number; the processing unit is further configured to verify the first request information according to the third key and the fourth message authentication code; and the transceiver is further configured to send second response information to the first client in a case where the first request information is verified, the second response information being used to indicate that the server accepts the first request information.

[0082] With reference to the fourth aspect, in some implementations of the fourth aspect, the first request information further includes a value of a second counter, the value of the second counter being used for uniqueness verification of the first request information.

[0083] With reference to the fourth aspect, in some implementations of the fourth aspect, the first message further includes a maximum value of a counter associated with at least one interface message of at least one service in the service, the maximum value of the counter being used for communication recovery after a first client failure or restart.

[0084] With reference to the fourth aspect, in some implementations of the fourth aspect, the transceiver is further configured to send a third message to the first client, the third message being used to indicate services that can be provided by the server, the third message including a second security policy option, the second security policy option being used to indicate that there is no corresponding security level for each interface in the service, receive a fourth message sent by the first client, the fourth message being used to indicate a security level corresponding to at least one interface in the service provided by the server, and send the first message to the first client according to the fourth message.

[0085] With reference to the fourth aspect, in some implementations of the fourth aspect, the first security policy option is preconfigured, or the first security policy option is carried in the first packet.

[0086] In a fifth aspect, a security access apparatus is provided, including at least one processor and a memory, the at least one processor coupled to the memory and configured to read and execute instructions in the memory so that the apparatus implements the method in any implementation of the first aspect or the second aspect.

[0087] In a sixth aspect, a computer readable storage medium is provided, which stores a computer program code, when the computer program code is run on a computer, the computer is caused to execute the method in any implementation of the first aspect or the second aspect.

[0088] In a seventh aspect, a chip is provided, which includes a circuit for executing the method in any implementation of the first aspect or the second aspect.

[0089] In an eighth aspect, a computer program product is provided, which includes a computer program, when the computer program is run, the computer is caused to execute the method in any implementation of the first aspect or the second aspect.

[0090] In a ninth aspect, a vehicle is provided, including the security access apparatus in any implementation of the third aspect or the fourth aspect. BRIEF DESCRIPTION OF DRAWINGS

[0091] FIG. 1 is a functional schematic diagram of a vehicle according to an embodiment of the present application;

[0092] FIG. 2 is a system architecture diagram of a system for protecting SOME / IP data based on a TLS protocol according to an embodiment of the present application;

[0093] FIG. 3 is a system architecture diagram of a system for protecting SOME / IP data based on a SecOC protocol according to an embodiment of the present application;

[0094] FIG. 4 is a system architecture to which a security access method according to an embodiment of the present application is applied;

[0095] FIG. 5 is a schematic flowchart of a security access method according to an embodiment of the present application;

[0096] FIG. 6 is a schematic flowchart of a security negotiation process according to an embodiment of the present application;

[0097] FIG. 7 is a schematic flowchart of another security negotiation process according to an embodiment of the present application;

[0098] FIG. 8 is a message format of SOME / IP provided by an embodiment of the present application;

[0099] FIG. 9 is a message integrity protection format of SOME / IP provided by an embodiment of the present application;

[0100] FIG. 10 is a message confidentiality protection format of SOME / IP provided by an embodiment of the present application;

[0101] FIG. 11 is a communication process of an event class message of SOME / IP provided by an embodiment of the present application;

[0102] FIG. 12 is a communication process of a method class message of SOME / IP provided by an embodiment of the present application;

[0103] FIG. 13 is a schematic flowchart of a client actively requesting a security policy option through a Find message provided by an embodiment of the present application;

[0104] FIG. 14 is a comparison schematic diagram of key deployment mode differences provided by an embodiment of the present application;

[0105] FIG. 15 is a schematic flowchart of another security negotiation process provided by an embodiment of the present application;

[0106] FIG. 16 is a schematic flowchart of another security negotiation process provided by an embodiment of the present application;

[0107] FIG. 17 is a schematic diagram of a secure access device provided by an embodiment of the present application;

[0108] FIG. 18 is a schematic diagram of another secure access device provided by an embodiment of the present application. DETAILED DESCRIPTION

[0109] In the description of the embodiments of the present application, unless otherwise specified, " / " represents the meaning of or, for example, A / B can represent A or B; "and / or" herein is only a description of the association relationship of the associated objects, which means that there can be three relationships, for example, A and / or B, which can represent: A exists alone, A and B exist together, and B exists alone. In the present application, "at least one" means one or more, and "multiple" means two or more. "At least one of the following" or the like means any combination of these items, including any combination of single item or multiple items. For example, at least one of a, b, or c can represent: a, b, c, a-b, a-c, b-c, or a-b-c, where a, b, and c can be single or multiple.

[0110] The prefix words such as "first", "second" in the embodiments of the present application are only used to distinguish different description objects, and have no limiting effect on the position, order, priority, quantity or content of the described objects. The use of ordinal words such as prefixes in the embodiments of the present application does not constitute a limitation on the described objects, and the description of the described objects should be referred to the description of the context in the claims or embodiments, and should not constitute redundant limitations because of the use of such prefix words.

[0111] In order to better understand the present application, first, the terms related to the present application are introduced.

[0112] (1) Scalable service-oriented middleware over IP (SOME / IP): enables efficient and reliable exchange of information between different electronic control units (ECUs), both within the same vehicle and through the vehicle's network to external devices.

[0113] (2) Transport layer security (TLS): used on TCP transport control protocol, used to ensure the security of communication.

[0114] (3) Data packet transport layer security (DTLS): used on protocol data unit, used to ensure the security of communication in the data packet environment.

[0115] (4) Protocol data unit (PDU): is the basic unit of data transmission in network communication.

[0116] (5) Secure onboard communication protocol (SecOC): mainly applied to the security communication scene in the vehicle network, especially in the data transmission involving safety-critical systems (such as automatic driving, braking system, power control system, etc.). It ensures the security of data communication between different ECUs in the vehicle, prevents malicious attackers from tampering with, forging or replaying attacks on the vehicle control system, and thus guarantees the safe operation of the vehicle.

[0117] (6) Offer message: a message entry, the server broadcasts the service instances it provides, simply speaking, the offer message is like an advertisement published by the server in the network, telling other components which services the server can provide.

[0118] (7) Replay attack: In a replay attack, an attacker captures legitimate messages and resends them later to fool the receiver.

[0119] (8) Integrity check: Mainly to ensure that the message or information is not tampered with during transmission, which can be achieved by using a message authentication code.

[0120] (9) Confidentiality check: Concerned about the encrypted message or information not being accessed by unauthorized third parties, confidentiality check is usually achieved through encryption technology, ensuring that the authorized server or client can decrypt and read the data content, even if the message or information is intercepted, it cannot be decrypted.

[0121] The technical solutions in the embodiments of the present application will be described below with reference to the accompanying drawings.

[0122] FIG. 1 is a functional schematic diagram of a vehicle 100 according to an embodiment of the present application.

[0123] The vehicle 100 can include various subsystems, such as a perception system 120, a computing platform 130, and a safety system 140. Alternatively, the vehicle 100 can include more or fewer subsystems, and each subsystem can include one or more components. In addition, each subsystem and component of the vehicle 100 can be interconnected by wired or wireless means.

[0124] The perception system 120 can include several sensors for sensing information about the environment surrounding the vehicle 100. For example, the perception system 120 can include a positioning system, which can be a global positioning system (GPS), a Beidou system, or other positioning systems. The perception system 120 can include one or more of an inertial measurement unit (IMU), a laser radar, a millimeter wave radar, an ultrasonic radar, and a camera.

[0125] Some or all of the functionality of the vehicle 100 can be controlled by the computing platform 130. The computing platform 130 can include processors 131-13n (n is a positive integer), which are circuits having a processing capability of signals. In one implementation, the processor can be a circuit having an instruction reading and running capability, such as a central processing unit (CPU), a microprocessor, a graphics processing unit (GPU) (which can be understood as a kind of microprocessor), a digital signal processor (DSP), and the like. In another implementation, the processor can implement certain functions through a logical relationship of hardware circuits, which is fixed or can be reconfigured, such as an application-specific integrated circuit (ASIC) or a programmable logic device (PLD) implemented hardware circuit, such as an FPGA. In the reconfigurable hardware circuit, the processor loads the configuration document to implement the hardware circuit configuration process, which can be understood as the process of the processor loading instructions to implement the functions of the above part or all units. In addition, the processor can also be a hardware circuit designed for artificial intelligence, which can be understood as a kind of ASIC, such as a neural network processing unit (NPU), a tensor processing unit (TPU), a deep learning processing unit (DPU), and the like. In addition, the computing platform 130 can also include a memory for storing instructions, and some or all of the processors 131-13n can call the instructions in the memory to implement corresponding functions.

[0126] The computing platform 130 can control the functionality of the vehicle 100 based on inputs received from various subsystems (e.g., the perception system 120). In some embodiments, the computing platform 130 can be used to provide control over many aspects of the vehicle 100 and its subsystems.

[0127] The security system 140 mainly functions to protect the confidentiality, integrity and authenticity of data transmission, prevent replay attacks, and ensure the overall security of the vehicle network. The server and the client can be located in the security system 140.

[0128] Optionally, the above components are only an example, and in actual application, components in each module can be added or deleted according to actual needs.

[0129] The vehicle 100 in the present application can include: a road vehicle, a water vehicle, an air vehicle, industrial equipment, agricultural equipment, or entertainment equipment, etc. For example, the vehicle 100 can be a vehicle (such as a commercial vehicle, a passenger vehicle, a motorcycle, a flying vehicle, a train, etc.), an industrial vehicle (such as a forklift, a trailer, a tractor, etc.), an engineering vehicle (such as an excavator, a bulldozer, a crane, etc.), an agricultural device (such as a mower, a harvester, etc.), a recreational device, a toy vehicle, etc. The type of the vehicle is not limited in the embodiments of the present application.

[0130] With the wide use of intelligent vehicles in daily life, the business of vehicle internal and external communication gradually increases. In this background, the middleware of communication service (SOME / IP protocol) is widely used. The application mode of the SOME / IP protocol is specifically: after the client receives the Offer message provided by the server, the client requests the method (Method) corresponding to the service (Service) or subscribes to the event (Event). If an unauthorized controller or an untrusted application program calls SOME / IP, or an untrusted service provider provides services, there will be a great security risk.

[0131] The SOME / IP protocol has three typical communication interfaces, which are a method remote function call interface (Method interface for short), an event interface, and a threshold (Field) interface. For the Method interface, when the client searches for the required service, within the effective existence time of the service, the client can send a Request request according to the functional demand, and the server can process the Request request based on the request response mechanism or the request non-response mechanism. For the event interface, the server can send a notification (including a notification for a state value or a notification for a triggering event) to the subscribed client. When sending the above notification, the server can perform unicast and multicast sending according to the function. For the threshold interface, which is used to manage certain "domain values" or "attribute values" of the server, the threshold interface can be used to obtain, set, or notify the change of certain data values. The service interface of the threshold interface includes: a Notifier threshold interface, a Getter threshold interface, and a Setter threshold interface. The above three interfaces can be summarized as a remote interface call method and a one-way event notification. The remote interface call method can mean that the client initiates a request, and the server processes the request and returns the result. The one-way event notification interface can mean that the server pushes a notification of a certain event to the client, and the client passively receives it without initiating a request.

[0132] Different interfaces usually have different security protection requirements in the same SOME / IP service instance, for example, some interfaces may need stricter identity verification and encryption measures to protect sensitive data; while some other interfaces may only need basic security measures to reduce communication delay and system load. However, the current security protection technology adopts a unified security protection strategy for all interfaces in the SOME / IP service, and this "one-size-fits-all" approach cannot balance system performance while ensuring system security, resulting in over-protection of system security or poor processing performance in some cases.

[0133] For example, as shown in FIG. 2, the TLS protocol performs identity authentication, key negotiation and secure communication at the transport layer. This protocol can enable communication subjects to establish a secure channel through a handshake process based on pre-set certificates or keys. All traffic transmitted through this channel is encrypted for protection, thereby ensuring data confidentiality and integrity. SOME / IP data can rely on this transmission channel to obtain effective security protection. However, in this architecture, all method messages, event messages and threshold messages for the same service instance are communicated through the same TCP or user data protocol (UDP). Since it is not possible to accurately distinguish which method messages, event messages and threshold messages within the service instance need protection, all messages are uniformly protected without distinction, which may cause the central processor to be overloaded due to excessive security traffic. Moreover, based on the TLS protocol to protect the transmission channel, due to the limitation of computing resources, the identity authentication of the transmission channel is usually performed at the component granularity rather than at the application program granularity, and therefore, this security measure cannot prevent attacks from untrusted applications running on trusted devices.

[0134] For example, as shown in FIG. 3, the SecOC protocol can protect the integrity of PDU granularity data. By pre-setting shared keys at the sending end and the receiving end of the SecOC message, it can prevent replay attacks through freshness value management technology within the life cycle of the vehicle. For different PDUs, different data identifiers can be set in advance to distinguish them, and SOME / IP data can use SecOC technology for data integrity protection. However, the SecOC protocol only supports one protection mode of message integrity protection and does not support other protection modes of messages. Moreover, since the freshness value is incremented within the life cycle of the vehicle, the use of the freshness value depends on the persistent storage, which has a higher requirement for the processing of after-sales scenarios such as maintenance and replacement. In addition, the SecOC protocol can only protect the business data of the routing relationship and cannot perform identity authentication and protection on the negotiation process of the SOME / IP message, and therefore, identity authentication of the subscriber cannot be implemented for the event interface, which has a risk of illegal subscription.

[0135] The embodiment of the application provides a secure access method, device and vehicle, different protection strategies and communication keys can be taken for different interfaces in the SOME / IP service, and the safe communication of the server and the client can be ensured, and the phenomenon of excessive security protection or poor processing performance of the system can be avoided.

[0136] Fig. 4 is a system architecture to which the secure access method provided by the embodiment of the application is applied.

[0137] As shown in Fig. 4, the system architecture includes a server and a client, the server includes a service provider, a service discovery module and a message distribution module, and the client includes a service invoker, a service discovery module and a message distribution module.

[0138] The service provider is a business subject that at least implements at least one of providing events, state notifications and executing services, the service invoker is a business subject that at least implements at least one of receiving events, state notifications, requesting service execution and obtaining execution results, the service discovery module is at least used for managing at least one of service publishing, service discovery and service subscription processes, and the message distribution module can perform SOME / IP message format encapsulation, message sending and receiving processing according to the processing result of the service discovery module.

[0139] When the system architecture is applied, the SOME / IP system can obtain security policy options provided by the service provider and the service invoker respectively (corresponding to the security policy option registration in Fig. 4), the service provider and the service invoker can register the security policy options into the service discovery module respectively after obtaining the security policy options, the service discovery modules in the server and the client can perform security negotiation based on the symmetric key and the security policy options, complete identity authentication and obtain the communication keys of the method interface, the event interface and the threshold interface, and the service discovery modules in the server and the client can deliver the negotiation result (the security policy options and the communication keys) to the message distribution module after the security negotiation is successful. The message distribution modules in the server and the client can perform fine-grained communication security protection based on the security policy options and the communication keys.

[0140] Optionally, the symmetric key can be a key pre-filled and stored in the client and the server before the vehicle is shipped, or the symmetric key can be a key negotiated by the client and the server based on a key exchange protocol.

[0141] It should be understood that the server in Fig. 4 can be understood as a component that provides services in the vehicle, and the client can be understood as a component that uses services in the vehicle.

[0142] It should also be understood that the system architecture shown in FIG. 4 is only an exemplary illustration, and does not limit the present application, and those skilled in the art can change the system architecture shown in FIG. 4 according to actual needs.

[0143] FIG. 5 is a schematic flowchart of a secure access method according to an embodiment of the present application. The method 500 can be applied to the system architecture of FIG. 4. The method 500 can include steps S501 to S504.

[0144] S501, the server sends a first message to the first client.

[0145] The first message is used to indicate at least the services that the server can provide, and the first message includes a first random number. For example, the first message is used to indicate that the server can provide a car light control service, a car window control service, an air conditioner adjustment service, or a sound control service.

[0146] In a possible implementation, the first message further includes a maximum value of a counter associated with at least one interface message of at least one service in the services, and the maximum value of the counter is used for communication recovery after the first client fails or restarts. In this way, by using the maximum value of the counter, even if the local counter of the first client is lost due to abnormal power failure or other factors, the first client can perform calculation based on the maximum value of the counter as an initial value after being online again, without the need to re-negotiate with the server, so that the first client can better cope with temporary failures.

[0147] In a possible implementation, before step S501, the method 500 further includes: the server sends a third message to the first client, the third message is used to indicate the services that the server can provide, and the third message includes a second security policy option, the second security policy option is used to indicate that there is no corresponding security level for each interface in the services; the first client sends a fourth message to the server according to the third message, the fourth message is used to indicate the security level corresponding to at least one interface in the services provided by the server. Correspondingly, in step S501, the server can send a first message to the first client according to the fourth message, the first message includes a first security policy option, and the first security policy option is used to indicate the security level corresponding to at least one interface of at least one service in the services. In this way, when the second security policy option is carried in the third message sent by the server, the client (the first client) that needs to provide a secure access method of the server can negotiate with the server, and the server sends the first message carrying the first security policy option. In this way, the differentiated secure access requirements of different clients can be met, and the security and flexibility of data transmission between the server and the client are taken into account.

[0148] S502, the first client determines at least one second key according to the first key, the first security policy option and the first random number.

[0149] The first key is a symmetric key, the first security policy option is used to indicate a security level corresponding to at least one interface of at least one service, and the at least one second key is used to verify a second message sent by the server.

[0150] For example, the first security policy option is used to indicate security levels corresponding to a threshold interface, a method interface and an event interface in a vehicle lamp control service.

[0151] Optionally, the first key can be a key pre-installed and stored in the first client and the server before the vehicle is manufactured, or the first key can be a key negotiated by the client and the server based on a key exchange protocol.

[0152] Optionally, the security level corresponding to the at least one interface can correspond to a security protection policy or a security protection mode corresponding to the at least one interface.

[0153] For example, the first security policy option indicates security levels corresponding to the threshold interface and the method interface in the vehicle lamp control service, and the security level corresponding to the method interface is higher than the security level corresponding to the threshold interface, which is equivalent to the first security option indicating that the method interface adopts an integrity protection policy and the threshold interface adopts a confidentiality protection policy, and the security degree of the confidentiality protection policy is higher than the security degree of the integrity protection policy.

[0154] In a possible implementation, the first security policy option is preconfigured, or the first security policy option is carried in the first message.

[0155] The first security policy option is preconfigured, including that the first client and the server configure the first security policy option in advance to be consistent through a communication detail table or a configuration tool.

[0156] In order to ensure the security of the derived at least one second key, the first client can perform security verification on the first message after receiving the first message.

[0157] In a possible implementation, when the first message further includes a first message authentication code, before step S502, the method 500 further includes: the first client determines a third key according to the first key and the first random number; the first client determines a second message authentication code according to the third key and the first message; and the first client determines that the second message authentication code and the first message authentication code are consistent. In this way, it is beneficial for the first client to quickly confirm whether the first message is tampered in the transmission process and the source is trustworthy, so as to derive the at least one second key for communication with the server in time.

[0158] Optionally, the determination that the second message authentication code is consistent with the first message authentication code can be understood as that the numerical values of the first message authentication code and the second message authentication code are the same.

[0159] Optionally, the determination that the second message authentication code is consistent with the first message authentication code can be understood as that the integrity verification of the first client on the first message passes.

[0160] In a possible implementation, when the first message further includes a first timestamp, before step S502, the method 500 further includes: determining, by the first client, that a difference between the second timestamp and the first timestamp is less than or equal to a preset threshold, the second timestamp being used to indicate a time at which the first client receives the first message. In this way, the first client can perform uniqueness verification on the first message according to the first timestamp carried in the first message, thereby reducing the risk of the first client being attacked by replay.

[0161] S503, the server sends a second message to the first client.

[0162] The second message includes data corresponding to the first service, and at least one service in the services includes the first service; the server can use at least one second key to encrypt the second message when sending the second message to the first client, and the at least one second key can be derived by the server based on the first key, the first security policy option and the first random number.

[0163] The message types of the second messages are different, and the interaction processes of the server and the first client can also be different.

[0164] In a possible implementation, the second message is an event message, and before step S503, the first client can send first subscription information to the server, the first subscription information including a third message authentication code, the third message authentication code being determined based on a third key and the first subscription information, or the third message authentication code being determined based on at least one second key and the first subscription information; after receiving the first subscription information, the server verifies the first subscription information according to the third message authentication code, and in a case where the first subscription information passes the verification, the server sends first response information to the first client, the first response information being used to indicate that the server accepts the first subscription information. In this way, it is beneficial for the server to quickly determine whether the first subscription information is from an expected sender, thereby facilitating the server to send the second message to the first client.

[0165] Exemplarily, when verifying the first subscription information, the server can determine a message authentication code based on the third key or the at least one second key and the first subscription information, and when the message authentication code is consistent with the third message authentication code, it can be considered that the first subscription information is verified, otherwise, the first subscription information is not verified.

[0166] Optionally, the first client can carry a second random number in the first subscription information, the second random number being a random number generated after the first client is powered on, and in step S502, the server can determine the third key based on the first key, the first random number and the second random number, so as to verify the first subscription information based on the third key. In this way, the security of the derived third key can be higher, and the risk of the third key being cracked by an attacker is reduced. On the other hand, the secure access method can be applied to a scenario where one server corresponds to multiple clients and the multiple clients are pre-stored with different keys, thereby expanding the scope of application of the secure access method.

[0167] Optionally, the first subscription information further includes a value of a first counter, and the value of the first counter is used for unique verification of the first subscription information. In this way, through the use of the first counter, the first subscription information is unique, and any attempt to repeatedly send the first subscription information will be identified and rejected by the server in time, thereby reducing the risk of replay attack on the server.

[0168] Exemplarily, the first client adds the first counter to the first subscription information when sending the first subscription information to the server, and after receiving the first subscription information, the server can extract the value of the first counter and detect whether the value of the first counter is greater than the value of the counter previously obtained by the server. If the value of the first counter is greater than the value of the counter previously obtained by the server, the unique verification of the first subscription information is passed, otherwise, the unique verification of the first subscription information is not passed.

[0169] In a possible implementation, when the second message is an event message, in step S503, the server can send the encrypted second message to multiple clients, the multiple clients including the first client, and the multiple clients can store the same first key. In this way, since the server and the multiple clients are pre-stored with the same derived key, the server can send the encrypted second message through multicast by using the at least one second key for one-time encryption, and in this way, the server is avoided from performing multiple encryption calculations, thereby saving the calculation overhead.

[0170] In a possible implementation, the second message is a method message, and before step S503, the first client sends first request information to the server, the first request information comprising: a fourth message authentication code determined based on the third key and the first request information, or a fourth message authentication code determined based on at least one second key and the first request information, or a first tag used for integrity verification of the first request information. In this way, the server can perform security verification on the first request information based on the fourth message authentication code or the first tag, so as to ensure that the first request information is not tampered with or forged in the information transmission process.

[0171] For example, the server verifies the first request information based on the fourth message authentication code in the same way as the server verifies the first subscription information based on the third message authentication code, which will not be described herein again.

[0172] Optionally, the first client can carry a second random number in the first request information, the second random number being a random number generated after the first client is powered on, and in step S502, the server can determine the third key based on the first key, the first random number and the second random number, and verify the first request information based on the third key. After the first request information is verified, the server can send second response information to the first client, the second response information being used to indicate that the server accepts the first request information. In this way, the security of the derived third key can be higher, and the risk of cracking the third key by an attacker can be reduced. On the other hand, the secure access method can be applied to a scenario in which one server corresponds to multiple clients and the multiple clients are preconfigured with different keys, thereby expanding the scope of application of the secure access method.

[0173] Optionally, the first request information further comprises a value of a second counter, and the value of the second counter is used for uniqueness verification of the first request information. In this way, the first request information is unique by using the second counter, and any attempt to repeatedly send the first request information can be identified and rejected by the server in time, thereby reducing the risk of replay attack on the server.

[0174] For example, the first client adds the second counter to the first request information when sending the first request information to the server, and after receiving the first request information, the server can extract the value of the second counter and detect whether the value of the second counter is greater than the value of the counter previously obtained by the server. If the value of the second counter is greater than the value of the counter previously obtained by the server, the uniqueness verification of the first request information is passed, otherwise, the uniqueness verification of the first request information is failed.

[0175] S504, the first client verifies the second message based on at least one second key.

[0176] Exemplarily, after the second message is verified, the first client can use data carried by the second message.

[0177] In the embodiments of the present application, the first client can generate at least one second key according to the first key, the first security policy option and the first random number, and verify the second message based on the at least one second key. In this way, different protection policies and communication keys are adopted for different interfaces in the SOME / IP service, which can ensure the secure communication between the server and the client while avoiding the phenomenon of excessive security protection or poor processing performance of the system. In addition, compared with the key derivation process of the asymmetric key, the use of the first key can improve the derivation efficiency of the at least one second key and save the computing resources of the first client and the server.

[0178] It should be understood that in various embodiments of the present application, the terms and / or descriptions of various embodiments are consistent and can be mutually referred to if there is no special description and logical conflict, and the technical features in different embodiments can be combined to form new embodiments according to their inherent logical relationship.

[0179] The first security policy option and the second security policy option in the security registration process and method 500 in FIG. 4 will be described in detail below.

[0180] Under the same SOME / IP service, there can be five different interface forms such as Method, Event, Field-Notifier, Field-Getter and Field-Setter, and the security policy option registration can be performed in the granularity of the interface, and the different messages under the same SOME / IP service are configured with security policy options respectively to meet the differentiated security requirements. Table 1 is an example of a security policy option configuration scheme (taking a vehicle lamp control service as an example).

[0181] Table 1

[0182] As can be seen from Table 1, different interface types can be configured with different security policy options, wherein the confidentiality protection has a large calculation overhead, and can be used to protect sensitive information to avoid eavesdropping of messages by attackers; the integrity protection can avoid tampering and impersonation of messages, and has a lower calculation overhead than the confidentiality protection; the no representation message is derived based on threat analysis to obtain a result that is not risky, and the message can not be protected; and the only authentication and no protection policy is for event and notification threshold interfaces, and can only authenticate the identity of a subscriber, and does not protect the service message (i.e., the second message in the method 500). In addition to the four security policy options shown in Table 1, the security policy options can include, but are not limited to, an optional integrity protection policy, i.e., a subscriber can require a service provider to perform identity authentication according to the needs of the subscriber, and the service provider does not forcibly require all service subscribers to perform authentication.

[0183] The security policy options described above can correspond to the security levels in the method 500, for example, the security levels from high to low are confidentiality protection, integrity protection, optional integrity protection, only authentication and no protection, and no protection policy. The first security policy option in the method 500 can include the confidentiality protection, only authentication and no protection, and integrity protection in Table 1, and the second security policy option can include the no protection policy.

[0184] It should be understood that the different security policy options described above can be applied to different security scenarios to achieve a balance between performance and security. In this application, all interfaces under the same service instance can use the same security policy option, for example, all threshold obtaining interfaces under the same service instance can use the confidentiality protection policy.

[0185] It should also be understood that the security levels corresponding to the different types of security policy options in Table 1 are not the same, but under the same security policy option, different types of interfaces can also have different security levels, or under the same security policy option, the same type of interface can also have different security levels due to different processing algorithms.

[0186] The process of deriving at least one second key by the server and the first client in the security negotiation process and the method 500 will be described in detail below with reference to FIGS. 6 to 10.

[0187] FIG. 6 is a schematic flowchart of a security negotiation process according to an embodiment of the present application, in which all service participants (including the first client and the server) are preconfigured with the same symmetric key (e.g., one car one key), and identity authentication and session key negotiation are performed based on the standard process of SOME / IP service discovery. The method 600 can include steps S601 to S606.

[0188] S601, the server obtains a random number 1, a timestamp 1 and a counter.

[0189] Specifically, a service provider in the server can generate a random number 1 (Random1) when first online, obtain a timestamp 1 (TimeStamp1) at that time, maintain an associated counter (seqCounter) for each service interface message, and initialize the counter to 0.

[0190] The random number 1 can be the first random number in the method 500, and the timestamp 1 can be the first timestamp in the method 500.

[0191] S602, the server sends an offer message to the first client.

[0192] The offer message can be the first message in the method 500.

[0193] Exemplarily, the application also provides an offer message format (data stream), which includes: message length, message type, random number, security policy option, timestamp, maximum value of counter and MAC value. The random number is used for key derivation of the server and the first client, the security policy option can be used to indicate the security level corresponding to at least one interface of at least one service in the SOME / IP service, the timestamp is used for uniqueness verification of the offer message, the MAC value is used for integrity verification of the offer message, and the maximum value of the counter is used for communication recovery after failure or restart of the first client.

[0194] For example, the offer message format can be as shown in Table 2, in which single type and group type are used to distinguish single event / method and event group scenario; all types can represent all interfaces under the service instance, and the security level represents the security level set for the interface.

[0195] Table 2

[0196] Specifically, in step S602, the offer message can carry a SecurityPolicyOption extension field (an extension field indicating the message format), which includes: security policy option, random number 1, timestamp 1, maximum value of counter, and MAC1 calculated according to the offer message, wherein the security policy option can be the first security policy option in the method 500, and the MAC1 can be the first message authentication code in the method 500.

[0197] Optionally, the SecurityPolicyOption can carry an Options Array defined by a secure digital communication protocol (SD) protocol.

[0198] Optionally, the key used in the MAC1 calculation can be derived based on a preset key and a random number, i.e., KeyD = derive(Key, Random); the content of the offer message used in the input calculation, and the algorithm used in the calculation can be selected from an integrity protection algorithm such as AES-128-CMAC.

[0199] Optionally, the offer message can be sent in the form of a broadcast.

[0200] Optionally, when the server is always online, the server can periodically send the offer message to the first client, in which the random number can remain consistent with the service online, and does not need to be regenerated, the timestamp is updated according to the latest time, and the maximum value of the counter is updated to the maximum value of the counter associated with all interfaces of the service. For example, the server sends the updated offer message to the first client, including random number 1, timestamp 2, maximum value of the counter, and MAC2.

[0201] Optionally, when the server is offline again due to abnormal reasons, a random number needs to be regenerated, and the negotiation is restarted from step S601. For example, after the renegotiation, the server sends the updated offer message to the first client, including: random number 2, timestamp 2, maximum value of the counter, and MAC3.

[0202] S603, the first client verifies the legality of the offer message.

[0203] Specifically, in order to subscribe to service messages, the first client can verify the legality of the message after receiving the offer message, and after successful verification, the first client and the server generate a consistent key.

[0204] Optionally, the service subscriber in the first client can perform key derivation based on the symmetric key and the random number 1 carried in the offer message, i.e., keyD = Derive(Key, Random), thereby obtaining the same derived key as the service provider, and completing the MAC1 value verification.

[0205] Optionally, the symmetric key can be a key pre-filled and stored in the first client and the server before the vehicle is shipped, or the symmetric key can be a key negotiated by the first client and the server based on a key exchange protocol.

[0206] Optionally, in order to avoid replay attacks, the service subscriber in the first client can verify the timestamp 1 carried in the offer message, and perform subsequent processing after successful verification.

[0207] After the first client completes the identity verification of the offer message, key derivation can be performed based on the security policy option. In order to save the number of managed keys, the number of keys consistent with the security level in the service can be derived, for example, keyD1 is derived for integrity protection, and keyD2 is derived for confidentiality protection.

[0208] Optionally, a key can be derived for each service interface message for protection, for example, there are two messages under the integrity protection policy, the first message derives keyD1 for protection, and the second message derives keyD2 for protection.

[0209] In the above process, the symmetric key can be the first key in method 500, the keyD can be the third key in method 500, and the keyD1 and keyD2 can be the second key in method 500.

[0210] S604, the first client sends first subscription information to the server.

[0211] Exemplarily, the application also provides a message format (data stream) of the first subscription information, which includes: message length, message type, counter and MAC value, wherein the MAC value is used for integrity verification of the first subscription information, and the counter is used for uniqueness verification of the first subscription information.

[0212] For example, the message format of the first subscription information can be as shown in Table 3, in which the first client can use keyD and the first subscription information to calculate the MAC value, and the value of the counter is monotonically increasing with the number of times of sending the first subscription information.

[0213] Table 3

[0214] In the above process, the counter can correspond to the first counter in method 500, and the MAC value can correspond to the third message authentication code in method 500.

[0215] Optionally, when the first client loses the local counter due to abnormal factors such as power failure (the first client is offline), the maximum value of the counter carried in the offer message can be used as the initial value for the calculation after the first client is online again, and the value of the counter is kept monotonically increasing, and the first client does not need to re-negotiate with the server.

[0216] S605, the server sends first response information to the first client.

[0217] Specifically, the server can perform legal verification on the received subscription message, and after the legal verification is passed, the first response information sent by the server to the first client includes an ACK subscription success response message, otherwise, the first response information sent by the server to the first client includes an NACK subscription failure response message.

[0218] S606, the server sends an event message to the first client.

[0219] Specifically, the event message can include data corresponding to the service, and the event message can be protected using the negotiated security policy option and key. After the first client successfully verifies the event message, the first client can use the data carried in the second message. The event message can be the second message in method 500.

[0220] In the embodiments of the application, for event messages, the server and the client can perform differentiated security negotiation based on a symmetric key system for different interfaces (including event interfaces and notification threshold interfaces) under the same SOME / IP service, so that differentiated security protection policies for different interfaces can be implemented, and unnecessary security calculation can be reduced.

[0221] FIG. 7 is a schematic flowchart of another security negotiation process provided by the embodiments of the application. In FIG. 7, all service participants (including the first client and the server) are pre-provisioned with the same symmetric key (for example, one key for one vehicle), and identity authentication and session key negotiation are performed based on the standard process of SOME / IP service discovery. Method 700 can include steps S701 to S706.

[0222] S701, the server obtains a random number 1, a timestamp 1 and a counter.

[0223] Specifically, the service provider in the server can generate a random number 1 (Random1) when first online, obtain a timestamp 1 (TimeStamp1) at that time, and maintain an associated counter (seqCounter) for each service interface message, and initialize the counter to 0.

[0224] The random number 1 can be a first random number in the method 500, and the timestamp 1 can be a first timestamp in the method 500.

[0225] S702, the server sends an offer message to the first client.

[0226] The offer message can be a first message in the method 500.

[0227] Exemplarily, the application also provides an offer message format (data stream), which includes: message length, message type, random number, security policy option, timestamp, maximum value of counter, and MAC value. The random number is used for key derivation of the server and the first client, the security policy option can be used to indicate the security level corresponding to at least one interface of at least one service in the SOME / IP service, the timestamp is used for uniqueness verification of the offer message, the MAC value is used for integrity verification of the offer message, and the maximum value of the counter is used for communication recovery after failure or restart of the first client.

[0228] For example, the offer message format can be as shown in Table 2.

[0229] Specifically, in step S702, the SecurityPolicyOption extension field (an extension field indicating the message format) can be carried in the offer message, and the extension field includes: security policy option, random number 1, timestamp 1, maximum value of counter, and MAC1 calculated according to the offer message.

[0230] Optionally, the offer message can be sent in the form of broadcast.

[0231] Optionally, when the server is always online, the server can periodically send the offer message to the first client. In this process, the random number can remain consistent with that when the service is online, and does not need to be regenerated, the timestamp is updated according to the latest time, and the maximum value of the counter is updated to the maximum value of the counter associated with all interface messages of the service. For example, the server sends an updated offer message to the first client, including random number 1, timestamp 2, maximum value of counter, and MAC2.

[0232] Optionally, when the server is offline due to abnormal reasons and then online again, the random number needs to be regenerated, and the negotiation is restarted from step S701. For example, after the re-negotiation, the server sends an updated offer message to the first client, including: random number 2, timestamp 2, maximum value of counter, and MAC3.

[0233] S703, the first client performs legality verification on the offer message.

[0234] Specifically, after receiving the offer message, the first client can verify the legality of the message, and after successful verification, the first client and the server generate a consistent key.

[0235] Optionally, the service subscriber in the first client can perform key derivation based on the symmetric key and the random number carried in the offer message, that is, keyD = Derive(Key, Random), so as to obtain the same derived key as the service provider and complete MAC value verification.

[0236] Optionally, the above symmetric key can be a key pre-installed and stored in the first client and the server before the vehicle is shipped, or the symmetric key can be a key negotiated by the client and the server based on a key exchange protocol.

[0237] Optionally, in order to avoid replay attacks, the service subscriber in the first client can verify the timestamp carried in the offer message, and after successful verification, subsequent processing is performed.

[0238] After the first client completes the verification of the offer message, key derivation can be performed based on the security policy option. In order to save the number of managed keys, the number of keys consistent with the security level in the service can be derived, for example, keyD1 is derived for integrity protection, and keyD2 is derived for confidentiality protection.

[0239] Optionally, a key can be derived for each service interface message for protection. For example, under the integrity protection strategy, there are two messages, the first message derives keyD1 for protection, and the second message derives keyD1 for protection.

[0240] In the above process, the symmetric key can be the first key in method 500, the keyD can be the third key in method 500, the keyD1 and the keyD2 can be the second key in method 500, and the security policy option can be the first security policy option in method 500.

[0241] S704, the first client sends a Request message to the server.

[0242] Exemplarily, the application also provides a message format (data stream) of a Request message, which comprises a message ID, a message length, a request ID, and a payload, the payload comprising a counter and a MAC value, or the payload comprising a counter, a TAG value, and an initialization vector (IV value), wherein the counter is used for unique verification of the Request message, the MAC value is used for integrity verification of the Request message, and the TAG value and the IV value are support parameters required for encryption or decryption calculation of the Request message.

[0243] Optionally, the message format further comprises a protocol version, an interface version, a message type, and a return code.

[0244] Specifically, the message format in the Request message can be as shown in FIGS. 8 to 10, and the value of the counter monotonically increases with the number of times of sending the Request message.

[0245] In the above process, the Request message can correspond to the first request information in the method 500, the MAC value can correspond to the fourth message authentication code in the method 500, the TAG value can correspond to the first tag in the method 500, and the counter can be the second counter in the method 500.

[0246] S705, the server sends a Request response message to the first client.

[0247] Specifically, the server can perform legality verification on the received Request message, and after the legality verification passes, the server can send a Request response message to the first client, otherwise, the Request response message can be ignored, and the Request response message can be the second response information in the method 500.

[0248] Optionally, in the case where the legality verification does not pass, the server can also send a response error message (Request Error) to the first client.

[0249] S706, the client verifies the Request response message.

[0250] Specifically, after the first client verifies successfully, the Request response message can be passed to the service invoker, so as to facilitate the service invoker to subsequently receive and process the data of the method class message.

[0251] In the embodiments of the present application, for the method class message, the server and the first client can perform differentiated security negotiation based on the symmetric key system for different interfaces (including the method interface, the threshold obtaining interface, and the threshold setting interface) under the same SOME / IP service, so that the differentiated security protection policy for different interfaces can be implemented, and unnecessary security calculation can be reduced.

[0252] The security communication process of the server and the first client in the methods 500 to 700 will be described in detail below with reference to FIG. 11 and FIG. 12.

[0253] After the service provider of the server and the service invoker of the first client complete the identity authentication, the key derivation based on the security policy option can be performed, so that the security policy option and the communication key (corresponding to the at least one second key in the method 500) for each message can be obtained; the service discovery module in the server and the first client transmits the security policy option and the communication key to the message distribution module, and the message distribution module can store each message in the form of key-value pair after receiving the security policy option, where the value includes the key and the information related to the security level associated with the message, which is used to support the processing of each message.

[0254] As shown in FIG. 11, for the event class message (including the event interface and the threshold notification), the message distribution module of the service provider sends the message after processing the message, and the service subscriber verifies the event class message according to the security policy option after receiving the event class message, and transmits the event class message to the software component (SWC) after the verification is successful. For the event multicast message, since the service subscriber and the service provider have the same preset key, the key derived based on the preset key is also the same, and the service provider can only perform security calculation once and then send the message through multicast, so that the calculation overhead can be saved. The above event class message can be the event class message in the method 500.

[0255] As shown in FIG. 12, for the method class message (including the method, the threshold obtaining, and the threshold setting), the service subscriber can protect the Request message according to the security policy option when sending the Request message, and the service provider can verify the Request message according to the security policy option when receiving the Request message, and then sends the Request message to the SWC after the verification is passed. The message distribution module in the server can process the Request response message according to the security policy option when the SWC sends the Request response message. The above method class message can be the method class message in the method 500.

[0256] FIG. 13 is a schematic flowchart of a method for a client to actively request a security policy option through a Find message according to an embodiment of the present application.

[0257] In the process of security negotiation between the server and the client, if the offer message sent by the server does not carry a security policy option, and a client (for example, a first client) requires to verify the legality of the server, the first client can actively request through a Find message, and the method 1300 can include the following steps.

[0258] S1301, the server sends a first offer message to the first client.

[0259] Specifically, the server does not require security access to events, methods or thresholds under the SOME / IP service when registering the security policy option, and therefore the first offer message sent by the server carries a security policy option of null. The security policy option can be the second security policy option in the method 500, and the first offer message can be the third message in the method 500.

[0260] S1302, the first client sends a Find message to the server.

[0261] Specifically, when the first client requires the server to provide identity verification due to security requirements, the first client can send a Find message to the server to indicate the server to provide a security policy option when receiving the first offer message and finding that the security policy option is null. The Find message can be the fourth message in the method 500.

[0262] Exemplarily, the present application further provides a message format (data stream) of the Find message, which includes a message length, a message type and a field extension item. The field extension item is used to indicate a security level corresponding to at least one interface of at least one service in the SOME / IP service provided by the server.

[0263] For example, the message format of the Find message can be as shown in Table 4.

[0264] Table 4

[0265] S1303, the server sends a second offer message to the first client.

[0266] Specifically, when the service end has a security capability, the needs of the first client can be met, that is, the service end sends a second offer message to the first client, the second offer message can be the first message in the method 500, and in the second offer message, the security policy option is set to optional integrity protection, allowing the first client to select as needed. Since the second offer message is transmitted in plaintext relative to other clients, the security policy option can be an optional integrity protection policy, rather than a confidentiality protection policy.

[0267] S1304, the first client sends first subscription information or a Request message to the service end.

[0268] Specifically, after the first client selects a secure way to access the service, the first client can send the service end first subscription information (event class message subscription) or a Request message (method class message communication).

[0269] S1305, the service end sends first response information or a Request response message to the first client.

[0270] Specifically, the service end can perform legality verification on the received first subscription information or Request message, and after the legality verification passes, the service end can send the first client first response information or a Request response message.

[0271] In the embodiments of the application, the negotiation method of the service end and the client can meet the differentiated security protection needs of the client, and the security and flexibility of service data transmission are taken into account, and is especially suitable for the scenario where the client uses the Find message for key business and needs the service provider to perform legality verification.

[0272] As shown in (a) of FIG. 14, in the method 600 and the method 700, the client and the service end prestore the same symmetric key (for example, one car one key), and if the service end and different clients share different keys, for example, as shown in (b) of FIG. 14, the service end and the first client share Key1, and the service end and the second client share the key Key2, then the security negotiation process can be implemented according to the steps of FIG. 15 and FIG. 16.

[0273] FIG. 15 is a schematic flowchart of another security negotiation process provided by the embodiments of the application, wherein when all service participants prestore the same key, the method 1500 can also be implemented according to the steps of the method 600, and the method 1500 can include the following steps.

[0274] S1501, the service end sends an offer message to the first client and the second client.

[0275] The offer message carries a SecurityPolicyOption extension field, which indicates a security policy option and a random number R1 generated after power-on.

[0276] S1502, the first client sends first subscription information to the server, and the second client sends second subscription information to the server.

[0277] Exemplarily, the application also provides another message format (data stream) of the first subscription information, which includes: message length, message type, random number, counter and MAC value, wherein the random number is used for key derivation of the server and the first client, the MAC value is used for integrity verification of the first subscription information, and the counter is used for uniqueness verification of the first subscription information.

[0278] For example, the message format of the first subscription information can be as shown in Table 5, in which the counter is monotonically increasing with the number of times of sending the first subscription information.

[0279] Table 5

[0280] Specifically, in step S1502, the first client can generate a random number R2 after power-on, and carry the random number R2 in the first subscription information sent to the server; the first client can perform key derivation based on the random numbers R1 and R2 and a preset key Key1 to obtain KeyD1, i.e. KeyD1=PRF(key1,R1,R2), and perform MAC calculation on the offer message | subscription message (| represents splicing) using KeyD1 as the MAC value carried in the first subscription information.

[0281] Correspondingly, the second client can generate a random number R3 after power-on, and carry the random number R3 in the second subscription information sent to the server; the second client can perform key derivation based on the random numbers R1 and R3 and a preset key Key2 to obtain KeyD2, i.e. KeyD2=PRF(key2,R1,R3), and perform MAC calculation on the offer message | subscription message (| represents splicing) using KeyD2 as the MAC value carried in the second subscription information. The format of the second subscription information can also be as shown in Table 5.

[0282] S1503, the server sends first subscription response information to the first client, and sends second subscription response information to the second client.

[0283] The service end can perform legality verification on the first subscription information. If the legality verification is passed, the first subscription response information returned to the first client includes an ACK message, otherwise, the first subscription response information returned to the first client includes a NACK subscription failure message. Correspondingly, the service end performs legality verification on the second subscription information. If the legality verification is passed, the second subscription response information returned to the second client includes an ACK message, otherwise, the second subscription response information returned to the second client includes a NACK subscription failure message.

[0284] Optionally, in order to support the event multicast scenario, the service end can send the first subscription response information and the second subscription response information after performing encryption on the multicast key after the legality verification is passed. The multicast key can be a key randomly generated by the service end according to the security policy option. The key for encryption of the multicast can be derived by R1 and R2, or R1 and R3.

[0285] S1504, the service end sends an event message to the first client and the second client.

[0286] In the process of sending the event message, the service end performs security protection by using the negotiated security policy option and the key. The event message can be the second message in the method 500.

[0287] In the embodiments of the application, for the event message and the scenario in which multiple clients save different keys, the service end can negotiate with multiple clients, and implement differential security protection policies for different interfaces under the same SOME / IP service, thereby reducing unnecessary security calculation.

[0288] FIG. 16 is a schematic flowchart of another security negotiation process provided by the embodiments of the application. When all service participants are pre-provisioned with the same key, the method 1600 can also be implemented according to the steps of the method 700. The method 1600 can include the following steps.

[0289] S1601, the service end sends an offer message to the first client and the second client.

[0290] The offer message carries a SecurityPolicyOption extension field, which is used to indicate the security policy option and the random number R1 generated after power-on. The offer message can be the first message in the method 500.

[0291] S1602, the first client sends a first Request message to the service end, and the second client sends a second Request message to the service end.

[0292] For the extension field part of the first Request message and the second Request message, the following two ways can be implemented.

[0293] In a possible implementation, the first Request message can be a first security subscription request message, the first security subscription request message including: a random number R2, a counter and a MAC1, and the second Request message can be a second security subscription request message, the second security subscription request message including: a random number R3, a counter and a MAC2.

[0294] In a possible implementation, the first client can send the first Request message to the server multiple times, and carry the random number R2, the counter and the MAC1 in the first first Request message, and if the first client receives the Request response message sent by the server, the first client can not carry the random number R2 in the subsequent first Request, and correspondingly, the second Request message can also be processed in a similar manner.

[0295] For the service content part in the first Request message and the second Request message, key derivation can be performed based on a security policy option for protection, and encryption calculation (for example, calculation using an AES-128-GCM algorithm) is performed using a policy specified by the server, as part of the Request message.

[0296] S1603, the server sends a first Request response message to the first client, and sends a second Request response message to the second client.

[0297] Specifically, the server can perform legality verification on the received first Request, and in the case where the legality verification is passed, sends a first Request response message to the first client, otherwise, the first Request can be ignored, and correspondingly, the server can perform legality verification on the received second Request message, and in the case where the legality verification is passed, sends a second Request response message to the second client, otherwise, the second Request can be ignored.

[0298] After step S1603, the server can send a method class message to the first client and the second client, the message being protected using a pre-negotiated security policy option and key, and the method class message can be the second message in method 500.

[0299] In the embodiments of the present application, for the method class message and in the scenario that multiple clients save different keys, the server can negotiate with the multiple clients, and implement differentiated security protection strategies for different interfaces (including method interfaces, threshold obtaining interfaces and threshold setting interfaces) under the same SOME / IP service, thereby reducing unnecessary security calculation.

[0300] It should be understood that in various embodiments of the present application, the terms and / or descriptions between various embodiments are consistent and can be mutually referred to if there is no special description and logical conflict, and the technical features in different embodiments can be combined to form new embodiments according to their inherent logical relationship.

[0301] FIG. 17 is a schematic diagram of a secure access device provided in an embodiment of the present application. The device 1700 can include a transceiver unit 1710, a storage unit 1720 and a processing unit 1730. The transceiver unit 1710 is configured to transceive instructions and / or data, the storage unit 1720 is configured to implement a corresponding storage function and store corresponding instructions and / or data, and the processing unit 1730 is configured to perform data processing so that the device 1700 implements the foregoing secure access method.

[0302] In one embodiment, the device 1700 is configured to perform the actions performed by the first client in the foregoing method embodiments.

[0303] The device 1700 includes a transceiver unit 1710 and a processing unit 1730. The transceiver unit 1710 is configured to receive a first message sent by a server, the first message being used to at least indicate services that can be provided by the server, the first message including a first random number. The processing unit 1730 is configured to determine at least one second key according to a first key, a first security policy option and the first random number, the first key being a symmetric key, the first security policy option being used to indicate a security level corresponding to at least one interface of at least one service in the services, the at least one second key being used to verify a second message sent by the server, the second message including data corresponding to the first service, the at least one service in the services including the first service.

[0304] In a possible implementation, the first message further includes a first message authentication code. The processing unit 1730 is further configured to determine a third key according to the first key and the first random number, determine a second message authentication code according to the third key and the first message, and determine that the second message authentication code is consistent with the first message authentication code.

[0305] In a possible implementation, the second message is an event message, and the transceiver 1710 is further configured to: send, to the server, first subscription information, the first subscription information including a third message authentication code, the third message authentication code being determined based on a third key and the first subscription information, or the third message authentication code being determined based on at least one second key and the first subscription information; and receive first response information, the first response information indicating that the server accepts the first subscription information.

[0306] In a possible implementation, the first subscription information further includes a second random number, the second random number being a random number generated after the first client is powered on; and the processing unit 1730 is specifically configured to determine the third key based on the first key, the first random number, and the second random number; and the processing unit 1730 is further configured to determine the third message authentication code based on the third key, the first message, and the first subscription information.

[0307] In a possible implementation, the first subscription information further includes a value of a first counter, the value of the first counter being used for uniqueness verification of the first subscription information.

[0308] In a possible implementation, the second message is a method message, and the transceiver 1710 is further configured to: send, to the server, first request information, the first request information including: a fourth message authentication code or a first label, the fourth message authentication code being determined based on a third key and the first request information, or the fourth message authentication code being determined based on at least one second key and the first request information, and the first label being used for confidentiality verification of the first request information.

[0309] In a possible implementation, the first request information further includes: a second random number, the second random number being a random number generated after the first client is powered on, and the second random number being used for security verification of the first request information; and the transceiver 1710 is further configured to receive second response information sent by the server, the second response information indicating that the server accepts the first request information.

[0310] In a possible implementation, the first request information further includes a value of a second counter, the value of the second counter being used for uniqueness verification of the first request information.

[0311] In a possible implementation, the first message further includes: a maximum value of a counter associated with at least one interface message of at least one service in the server, the maximum value of the counter being used for communication recovery after failure or restart of the first client.

[0312] In a possible implementation, the first message further includes a first timestamp, and the processing unit 1730 is further configured to determine that a difference between a second timestamp and the first timestamp is less than or equal to a preset threshold, the second timestamp indicating a time at which the first client receives the first message.

[0313] In a possible implementation, the transceiver 1710 is further configured to receive a third message sent by the server, the third message being used to indicate services that can be provided by the server, the third message comprising a second security policy option, the second security policy option being used to indicate that no corresponding security level exists for each interface in the services; and the processing unit 1730 is further configured to send a fourth message to the server according to the third message, the fourth message being used to indicate the security level corresponding to at least one interface in the services provided by the server.

[0314] In a possible implementation, the first security policy option is preconfigured, or the first security policy option is carried in the first message.

[0315] In an embodiment, the apparatus 1700 is configured to perform actions performed by the server in the above-described method embodiments.

[0316] The apparatus 1700 comprises a transceiver 1710 and a processing unit 1730. The transceiver 1710 is configured to send a first message to a first client, the first message being used to at least indicate services that can be provided by the server, the first message comprising a first random number. The processing unit 1730 is configured to determine at least one second key according to a first key, a first security policy option, and the first random number, the first key being a symmetric key, the first security policy option being used to indicate a security level corresponding to at least one interface of at least one service in the services, the at least one second key being used to encrypt a second message, the second message comprising data corresponding to the first service, the at least one service in the services comprising the first service.

[0317] In a possible implementation, the first message further comprises a first message authentication code. The processing unit 1730 is further configured to determine a third key according to the first key and the first random number, and determine the first message authentication code according to the third key and the first message.

[0318] In a possible implementation, the second message is an event-type message. The transceiver 1710 is further configured to receive first subscription information sent by the first client, the first subscription information comprising a third message authentication code, the third message authentication code being determined based on the third key and the first subscription information, or the third message authentication code being determined based on the at least one second key and the first subscription information. The processing unit 1730 is further configured to verify the first subscription information according to the third message authentication code and the third key. The transceiver 1710 is further configured to send first response information to the first client in a case where the first subscription information is verified, the first response information being used to indicate that the server accepts the first subscription information.

[0319] In a possible implementation, the first subscription information further includes a second random number, the second random number being a random number generated after the first client is powered on; and the processing unit 1730 is specifically configured to determine the third key according to the first key, the first random number and the second random number.

[0320] In a possible implementation, the first subscription information further includes a value of a first counter, the value of the first counter being used for uniqueness verification of the first subscription information.

[0321] In a possible implementation, the processing unit 1730 is further configured to encrypt the second message according to the at least one second key, and send the encrypted second message to the plurality of clients, the plurality of clients including the first client.

[0322] In a possible implementation, the second message is a method-type message, and the transceiver unit 1710 is further configured to receive first request information sent by the first client, the first request information including: a fourth message authentication code or a first tag, the fourth message authentication code being determined based on the third key and the first request information, or the fourth message authentication code being determined based on the at least one second key and the first request information, and the first tag being used for confidentiality verification of the first request information.

[0323] In a possible implementation, the first request information includes: the fourth message authentication code and a second random number, the second random number being a random number generated after the first client is powered on; the processing unit 1730 is specifically configured to determine the third key according to the first key, the first random number and the second random number; and the processing unit 1730 is further configured to verify the first request information according to the third key and the fourth message authentication code; and the transceiver unit 1710 is further configured to send second response information to the first client in a case where the first request information is verified, the second response information being used to indicate that the server accepts the first request information.

[0324] In a possible implementation, the first request information further includes a value of a second counter, the value of the second counter being used for uniqueness verification of the first request information.

[0325] In a possible implementation, the first message further includes: a maximum value of a counter associated with at least one interface message of at least one service in the service, the maximum value of the counter being used for communication recovery after the first client fails or restarts.

[0326] In a possible implementation, the transceiver 1710 is further configured to: send a third message to the first client, the third message being used to indicate services that the server can provide, the third message comprising a second security policy option, the second security policy option being used to indicate that no security level corresponds to each interface in the services; receive a fourth message sent by the first client, the fourth message being used to indicate a security level corresponding to at least one interface in the services provided by the server; and the transceiver 1710 is specifically configured to send the first message to the first client according to the fourth message.

[0327] In a possible implementation, the first security policy option is preconfigured, or the first security policy option is carried in the first message.

[0328] FIG. 18 is a schematic diagram of another security access device provided by an embodiment of the present application.

[0329] The device 1800 comprises a memory 1810, a processor 1820, and a communication interface 1830. The memory 1810, the processor 1820, and the communication interface 1830 are connected through an internal connection path. The memory 1810 is configured to store instructions, the processor 1820 is configured to execute the instructions stored in the memory 1810 to control the communication interface 1830 to acquire information, so that the device 1800 implements the security access method described above. Optionally, the memory 1810 can be coupled to the processor 1820 through an interface, or the memory 1810 can be integrated with the processor 1820.

[0330] It should be noted that the communication interface 1830 uses a transceiving device such as but not limited to a transceiver. The communication interface 1830 can also comprise an input / output interface.

[0331] The processor 1820 stores one or more computer programs, and the one or more computer programs comprise instructions. When the instructions are executed by the processor 1820, the device 1800 performs the security access method in the above-mentioned embodiments.

[0332] In the implementation process, each step of the above method can be completed by integrated logic circuits of hardware in the processor 1820 or instructions in the form of software. The method disclosed in the embodiments of the present application can be directly embodied as hardware processor execution, or executed by a combination of hardware and software modules in the processor. The software module can be located in a storage medium in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, register, etc. The storage medium is located in the memory 1810, and the processor 1820 reads the information in the memory 1810 and combines the hardware to complete the steps of the above method. To avoid repetition, it will not be described in detail here.

[0333] Optionally, the communication interface 1830 in FIG. 18 can implement the transceiver unit 1710 in FIG. 17, the memory 1810 in FIG. 18 can implement the storage unit 1720 in FIG. 17, and the processor 1820 in FIG. 18 can implement the processing unit 1730 in FIG. 17.

[0334] The embodiment of the present application further provides a computer readable storage medium, which stores program codes, and when the program codes are run on a computer, the computer is caused to execute any one of the methods in FIG. 5 to FIG. 7, FIG. 13, FIG. 15 to FIG. 16.

[0335] The embodiment of the present application further provides a computer program product, which comprises a computer program, and when the computer program is run, the computer is caused to execute any one of the methods in FIG. 5 to FIG. 7, FIG. 13, FIG. 15 to FIG. 16.

[0336] The embodiment of the present application further provides a chip, which comprises: a circuit, which is used to execute any one of the methods in FIG. 5 to FIG. 7, FIG. 13, FIG. 15 to FIG. 16.

[0337] The embodiment of the present application further provides a vehicle, which comprises: the secure access device as shown in FIG. 17 or FIG. 18.

[0338] Those skilled in the art can clearly understand that the units and algorithm steps of the examples described in combination with the embodiments disclosed herein can be realized by electronic hardware or a combination of computer software and electronic hardware. Whether the functions are performed in hardware or software mode depends on the specific application and design constraints of the technical solution. The skilled person can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the present application.

[0339] Those skilled in the art can clearly understand that, for the convenience and brevity of the description, the specific working process of the system, device and unit described above can refer to the corresponding process in the foregoing method embodiments, which will not be described here.

[0340] In several embodiments provided in the present application, it should be understood that the disclosed system, device and method can be implemented in other manners. For example, the described device embodiments are merely schematic. The division of the units is merely logical function division. There can be other division manners in actual implementation. For example, a plurality of units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the displayed or discussed mutual couplings or direct couplings or communication connections can be indirect couplings or communication connections through some interfaces, devices or units, and can be in electrical, mechanical or other forms.

[0341] The units described as separate components can or can not be physically separate, and the components shown as units can or can not be physical units, i.e., can be located in one place, or can be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the embodiment.

[0342] In addition, each functional unit in the various embodiments of the present application can be integrated into a processing unit, or each unit can be a physically independent unit, or two or more units can be integrated into a unit.

[0343] If the functions are realized in the form of software function units and sold or used as independent products, they can be stored in a computer readable storage medium. Based on this understanding, the technical solutions of the present application can be embodied in the form of a software product, and the computer software product is stored in a storage medium, and includes a number of instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present application. The foregoing storage medium includes: a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, and various media that can store program codes.

[0344] The above description is merely a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art can easily think of changes or replacements within the technical scope disclosed in the present application, which should be covered within the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.

Claims

1. A method of secure access, characterized by, The method is applied to a first client, and the method comprises: receiving a first message sent by a server, the first message being used for at least indicating services that can be provided by the server, the first message comprising a first random number; determining at least one second key according to a first key, a first security policy option and the first random number, the first key being a symmetric key, the first security policy option being used for indicating a security level corresponding to at least one interface of at least one service in the services, the at least one second key being used for verifying a second message sent by the server, the second message comprising data corresponding to a first service, the at least one service in the services comprising the first service.

2. The method of claim 1, wherein, The first message further comprises a first message authentication code, and before the determining at least one second key according to a first key, a first security policy option and the first random number, the method further comprises: determining a third key according to the first key and the first random number; determining a second message authentication code according to the third key and the first message; determining that the second message authentication code is consistent with the first message authentication code.

3. The method of claim 2, wherein, The second message is an event type message, and the method further comprises: sending first subscription information to the server, the first subscription information comprising a third message authentication code, the third message authentication code being determined based on the third key and the first subscription information, or the third message authentication code being determined based on the at least one second key and the first subscription information; receiving first response information, the first response information being used for indicating that the server accepts the first subscription information.

4. The method of claim 3, wherein, The first subscription information further comprises a second random number, the second random number being a random number generated after the first client is powered on; The determining a third key according to the first key and the first random number comprises: determining the third key according to the first key, the first random number and the second random number; Before the sending first subscription information to the server, the method further comprises: determining the third message authentication code according to the third key, the first message and the first subscription information.

5. The method of claim 3 or 4, wherein, The first subscription information further comprises a value of a first counter, the value of the first counter being used for verifying uniqueness of the first subscription information.

6. The method of claim 2, wherein, The second message is a method type message, and the method further comprises: sending first request information to the server, the first request information comprising: a fourth message authentication code or a first label, the fourth message authentication code being determined based on the third key and the first request information, or the fourth message authentication code being determined based on the at least one second key and the first request information, the first label being used for checking confidentiality of the first request information.

7. The method of claim 6, wherein, The first request information further comprises a second random number, the second random number being a random number generated after the first client is powered on, the second random number being used for security verification of the first request information, and the method further comprises: receive second response information sent by the server, the second response information being used to indicate that the server accepts the first request information.

8. The method of claim 6 or 7, wherein, The first request information further comprises a value of a second counter, and the value of the second counter is used for verifying uniqueness of the first request information.

9. The method of any one of claims 1 to 8, wherein, The first message further comprises a maximum value of a counter associated with at least one interface message of at least one service in the service, and the maximum value of the counter is used for communication recovery after the first client fails or restarts.

10. The method of any one of claims 1 to 9, wherein, The first message further comprises a first timestamp, and before determining the at least one second key according to the first key, the first security policy option and the first random number, the method further comprises: determining that a difference between a second timestamp and the first timestamp is less than or equal to a preset threshold, and the second timestamp is used to indicate a time at which the first client receives the first message.

11. The method of any one of claims 1 to 10, wherein, Before receiving the first message sent by the server, the method further comprises: receiving a third message sent by the server, the third message being used to indicate services that can be provided by the server, and the third message comprising a second security policy option, the second security policy option being used to indicate that there is no corresponding security level for each interface in the service; sending a fourth message to the server according to the third message, and the fourth message being used to indicate that the server provides a security level corresponding to at least one interface in the service.

12. The method of any one of claims 1 to 11, wherein, The first security policy option is preconfigured, or the first security policy option is carried in the first message.

13. A method of secure access, characterized by The method is applied to a server, and the method comprises: sending a first message to a first client, the first message being used to at least indicate services that can be provided by the server, and the first message comprising a first random number; determining at least one second key according to a first key, a first security policy option and the first random number, the first key being a symmetric key, the first security policy option being used to indicate a security level corresponding to at least one interface of at least one service in the service, and the at least one second key being used to encrypt a second message, the second message comprising data corresponding to a first service, and the at least one service in the service comprising the first service.

14. The method of claim 13, wherein, The first message further comprises a first message authentication code, and before sending the first message to the first client, the method further comprises: determining a third key according to the first key and the first random number; determining the first message authentication code according to the third key and the first message.

15. The method of claim 14, wherein, The second message is an event type message, and the method further comprises: receiving first subscription information sent by the first client, the first subscription information comprising a third message authentication code, the third message authentication code being determined based on the third key and the first subscription information, or the third message authentication code being determined based on the at least one second key and the first subscription information; verifying the first subscription information according to the third message authentication code and the third key; In a case where the first subscription information is verified, a first response information is sent to the first client, the first response information being used to indicate that the service end accepts the first subscription information.

16. The method of claim 15, wherein, The first subscription information further comprises a second random number, the second random number being a random number generated after the first client is powered on. The third key is determined according to the first key and the first random number, comprising: The third key is determined according to the first key, the first random number and the second random number.

17. The method of claim 15 or 16, wherein, The first subscription information further comprises a value of a first counter, the value of the first counter being used for unique verification of the first subscription information.

18. The method of any one of claims 15 to 17, wherein, The method further comprises: The second message is a method type message, and the method further comprises:

19. The method of claim 14, wherein, The first request information comprises a fourth message authentication code or a first label, the fourth message authentication code being determined based on the third key and the first request information, or the fourth message authentication code being determined based on the at least one second key and the first request information, and the first label being used for confidentiality verification of the first request information. The first request information comprises the fourth message authentication code and a second random number, the second random number being a random number generated after the first client is powered on.

20. The method of claim 19, wherein, The third key is determined according to the first key and the first random number, comprising: The third key is determined according to the first key, the first random number and the second random number. The method further comprises: The first request information is verified according to the third key and the fourth message authentication code; In a case where the first request information is verified, a second response information is sent to the first client, the second response information being used to indicate that the service end accepts the first request information. The first request information further comprises a value of a second counter, the value of the second counter being used for unique verification of the first request information.

21. The method of claim 19 or 20, wherein, The first message further comprises a maximum value of a counter associated with at least one interface message of at least one service in the service, the maximum value of the counter being used for communication recovery after the first client fails or restarts.

22. The method of any one of claims 13 to 21, wherein, The first message further comprises a first time stamp, the first time stamp being used for unique verification of the first message.

23. The method of any one of claims 13 to 22, wherein, Before the first message is sent to the first client, the method further comprises:

24. The method of any one of claims 13 to 23, wherein, A third message is sent to the first client, the third message being used to indicate services that can be provided by the service end, the third message comprising a second security policy option, the second security policy option being used to indicate that there is no corresponding security level for each interface in the service; A fourth message is received from the first client, the fourth message being used to indicate that the service end provides a security level corresponding to at least one interface in the service; The first message is sent to the first client, comprising: ​ According to the fourth message, the first message is sent to the first client.

25. The method of any one of claims 13 to 24, wherein, The first security policy option is preconfigured, or the first security policy option is carried in the first message.

26. A secure access device, comprising: comprise units or modules for performing the method of any one of claims 1-12.

27. A secure access device, comprising: comprise units or modules for performing the method of any one of claims 13-25.

28. A secure access device, comprising: comprise a processor and a memory, the processor coupled to the memory, the memory for storing a computer program or instructions, and the processor for executing the computer program or instructions in the memory, so that the method of any one of claims 1-12 is performed.

29. A secure access device, comprising: comprise a processor and a memory, the processor coupled to the memory, the memory for storing a computer program or instructions, and the processor for executing the computer program or instructions in the memory, so that the method of any one of claims 13-25 is performed.

30. A chip, characterized by The chip comprises a circuit for performing the method of any one of claims 1-25.

31. A computer readable storage medium, characterized in that, The computer readable storage medium stores program code, which, when executed on a computer, causes the computer to perform the method of any one of claims 1-25.

32. A computer program product, characterised in that, The computer product comprises a computer program, which, when executed by a processor, causes the method of any one of claims 1-25 to be performed.

33. A vehicle characterized by The vehicle comprises the apparatus of claims 26 and 27, or the vehicle comprises the apparatus of claims 28 and 29.

Images