Sdv-based automotive internal network system with security functions in some / ip communication

Abstract

An internal vehicle network system according to one embodiment may be configured to include: a computing device that downloads and installs a package of client software; a plurality of zone controllers that each control at least one electronic device within the vehicle; and a central control unit that mediates communication between the computing device and the plurality of zone controllers.

Description

Technology Field

[0001] The embodiments disclosed in this specification relate to an SDV-based in-vehicle network system equipped with security functions in SOME / IP communication. Background Technology

[0002] SOME / IP (Scalable Service-Oriented Middleware over IP) communication, used in SDV (Software-Defined Vehicle)-based internal vehicle networks, is a communication method designed to enable electronic control units (ECUs) within the vehicle to efficiently exchange data with each other. In an SDV environment, since vehicle functions and performance are defined and controlled by software, a stable and flexible communication protocol is essential.

[0003] SOME / IP is a representative communication protocol that meets the requirements of SDV-based in-vehicle networks and supports various in-vehicle services and data exchange.

[0004] Specifically, SOME / IP is a protocol developed for communication based on a Service-Oriented Architecture (SOA) in vehicles. SOME / IP enables inter-service communication over IP-based networks and is primarily used in the Adaptive AUTOSAR Platform. The Adaptive AUTOSAR Platform is designed to support high-performance data transmission and efficiently handle communication between complex automotive systems.

[0005] In an SDV environment, features can be added or changed through software updates, and SOME / IP provides this flexibility, allowing necessary services and events to be easily added or removed.

[0006] In the SOME / IP protocol, each service possesses unique identifiers called a Service ID and an Instance ID. If a client application knows only the Service ID and Instance ID, it can access a specific service and send requests. Since the SOME / IP protocol interface lacks built-in security features, it is possible to connect to the service without authentication or access control. This vulnerability can be exploited through the exposure of FIDL (Franca Interface Definition Language) or FDEPL (Franca Deployment) files, potentially allowing malicious users to access services, cause the system to operate in unintended ways, or access sensitive data.

[0007] In other words, SOME / IP lacked an authentication mechanism in its initial design, resulting in a deficiency in the ability to verify whether each communication node is trustworthy. This vulnerability can be exploited to allow malicious nodes to impersonate service requests or responses. The problem to be solved

[0008] The embodiments disclosed in this specification are embodiments intended to solve the technical problems described above, and the purpose is to provide an SDV-based in-vehicle network system equipped with security functions in SOME / IP communication that can prevent unauthorized malicious applications from operating as SOME / IP clients and controlling electronic control units inside the vehicle by applying information for authentication to the option fields or payloads of SOME / IP protocol messages. means of solving the problem

[0009] In one embodiment, an internal vehicle network system may be configured to include: a computing device that downloads and installs a package of client software; a plurality of zone controllers that each control at least one electronic device within the vehicle; and a central control unit that mediates communication between the computing device and the plurality of zone controllers.

[0010] Specifically, the computing device may be configured to include: an OTA client module that downloads a package of the client software; a UCM module that receives and installs the package of the client software from the OTA client module; and a client software module which is a module of the client software installed by the UCM module.

[0011] The above UCM module obtains SOME / IP information from metadata included in the package of the client software and generates an authentication key string based on the SOME / IP information. The above UCM module may generate the key string based on a value formed by combining at least one of a number or character received from a user and at least one of a plurality of data included in the SOME / IP information.

[0012] Specifically, the UCM module generates the authentication key string for each service ID, instance ID, and client ID included in the SOME / IP information and stores it in a security management table.

[0013] In addition, each of the above multiple zone controllers stores or updates the part corresponding to the zone controller from the security management table in the management table for the corresponding zone controller.

[0014] Additionally, the computing device transmits a message containing the authentication key string in the option field of the SOME / IP message when searching for a service by the client software module. Accordingly, each of the plurality of zone controllers transmits a message to the computing device if the service ID, instance ID, client ID, and authentication key string included in the management table for the corresponding zone controller are identical to the service ID, instance ID, client ID, and authentication key string included in the SOME / IP message received by the corresponding zone controller.

[0015] In addition, the computing device transmits a message by means of the client software module, including the authentication key string in the payload of the message of the SOME / IP. Accordingly, each of the plurality of zone controllers transmits a message to the computing device in case the service ID, instance ID, client ID, and authentication key string included in the management table for the corresponding zone controller are identical to the service ID, instance ID, client ID, and authentication key string included in the message of the SOME / IP received by the corresponding zone controller. Effects of the invention

[0016] According to an SDV-based in-vehicle network system equipped with security functions in SOME / IP communication of the embodiments disclosed in this specification, by applying information for authentication to the option field or payload of a SOME / IP protocol message, it is possible to prevent unauthorized malicious applications from operating as SOME / IP clients and controlling electronic control units inside the vehicle. Brief explanation of the drawing

[0017] FIG. 1 is a configuration diagram of an SDV-based in-vehicle network system equipped with security functions in SOME / IP communication according to one embodiment. FIG. 2 is a diagram illustrating the structure of an on-wire format of SOME / IP according to one embodiment. Figure 3 is a sequence diagram of various communication methods of various SOME / IP protocols. Figure 4 is a diagram explaining the structure of a message during service discovery in the SOME / IP protocol. FIG. 5 is an explanatory diagram of the installation process of client software in an SDV-based in-vehicle network system equipped with security functions in SOME / IP communication according to one embodiment. FIG. 6 is an explanatory diagram of a security management table according to one embodiment. FIG. 7 is an explanatory diagram of a method for using a security management table in an SDV-based in-vehicle network system equipped with security functions in SOME / IP communication according to one embodiment. Specific details for implementing the invention

[0018] Hereinafter, an SDV-based in-vehicle network system equipped with security functions in SOME / IP communication according to embodiments of the present disclosure will be described in detail with reference to the attached drawings. It should be understood that the following embodiments of the present disclosure are merely for the purpose of embodying the present disclosure and do not limit or restrict the scope of the rights of the present disclosure. Anything that can be easily inferred by a person skilled in the art to which the present disclosure pertains from the detailed description and embodiments of the present disclosure is interpreted as falling within the scope of the rights of the present disclosure.

[0020] FIG. 1 shows a configuration diagram of an SDV-based in-vehicle network system (100) equipped with security functions in SOME / IP communication according to one embodiment.

[0021] An SDV-based in-vehicle network system (100) equipped with a security function in SOME / IP communication according to one embodiment uses the SOME / IP protocol. In addition, an SDV-based in-vehicle network system (100) equipped with a security function in SOME / IP communication according to one embodiment may be configured to include a computing device (10), a plurality of zone controllers (20_1, 20_2, 20_3, 20_4), and a central control unit (30).

[0023] The computing device (10) operates as a client and downloads and installs a package of client software. The client software package can be downloaded from a server (S) connected to a network outside the vehicle.

[0024] The computing device (10) is also referred to as a High-Performance Computer (HPC) and is a high-performance computer designed to handle complex tasks such as ADAS, infotainment systems, and autonomous driving functions.

[0026] Each of the multiple zone controllers (20_1, 20_2, 20_3, 20_4) serves to control at least one electronic device (E) within the vehicle. Specifically, each of the multiple zone controllers (20_1, 20_2, 20_3, 20_4) is a controller that centrally manages and controls the functions of multiple electronic devices (E) based on each zone within the vehicle. In traditional vehicle networks, ECUs were distributed individually for each function, but the zone controllers (20_1, 20_2, 20_3, 20_4) have a structure that integrates and manages functions in specific physical zones (e.g., front, rear, left, right, etc.) as a single controller.

[0027] The central control unit (30) acts as an intermediary for communication between the computing device (10) and a plurality of zone controllers (20_1, 20_2, 20_3, 20_4). Specifically, the central control unit (30) is also referred to as a CCU (Central Communication Unit or Connectivity Control Unit) and primarily manages the communication and connectivity functions of the vehicle. That is, the central control unit (30) acts as a gateway connecting the vehicle to the outside world and manages various data communications inside and outside the vehicle.

[0029] Before providing a detailed description of the SDV-based vehicle internal network system (100) equipped with security functions in SOME / IP communication according to one embodiment, SOME / IP will be described.

[0030] FIG. 2 is a diagram illustrating the structure of an on-wire format of SOME / IP according to one embodiment.

[0031] Specifically, the SOME / IP on-wire format defines the binary structure of messages used by the SOME / IP protocol to transmit and receive data over a network. In other words, it refers to the data format used when SOME / IP messages are actually transmitted through a network. This format provides a standardized structure for how each message field is arranged and interpreted.

[0032] As can be seen from Figure 2, the SOME / IP message is divided into a header and a payload, and each field is arranged in a fixed size and order.

[0033] The header contains multiple fields to define and manage message information. Specifically, the Message ID includes the Service ID and Method ID, while the Request ID includes the Client ID and Session ID.

[0034] Here, a service ID is a unique identifier representing a specific service (function). In addition, one service ID corresponds to the information of one zone controller (20_1, 20_2, 20_3, 20_4). That is, one zone controller (20_1, 20_2, 20_3, 20_4) can be identified by one service ID.

[0035] The method ID is an identifier that identifies a specific method called within the service. The request ID is a unique identifier that identifies the session associated with the client that sent the request. Additionally, the client ID is a unique identifier that identifies the computing device (10), i.e., the client software module (13). The session ID is an identifier that associates a specific request with a response.

[0037] Figure 3 shows a sequence diagram for various communication methods of various SOME / IP protocols.

[0038] As can be seen from FIG. 3, various types of message transmission and reception can be performed between each of the computing device (10) and the plurality of zone controllers (20_1, 20_2, 20_3, 20_4).

[0039] A method call is a request-response communication consisting of a request and a response. This method call requires a response unless it is a "Fire & Forget" method, and an error may occur if it fails.

[0040] The event callback is an event-based communication method consisting of a subscribe and a publish step. The event callback can be used to notify of an event when a specific sensor of a vehicle reaches a specific value. That is, the event callback is an event-based method in which each of the multiple zone controllers (20_1, 20_2, 20_3, 20_4) provides a notification to the computing device (10) when a specific event occurs.

[0041] A notification callback is a method of providing notification about changes in an attribute. That is, a notification callback is a method in which each of the multiple zone controllers (20_1, 20_2, 20_3, 20_4) provides a notification to the computing device (10) when the value of a specific field or attribute changes.

[0043] Figure 4 is a diagram explaining the structure of a message during service discovery in the SOME / IP protocol.

[0044] Messages for service discovery are used to locate a desired service on a network, check its status, and announce subscriptions or service offerings. The primary purpose of service discovery is to provide information on service availability and location.

[0045] When searching for a service, the service ID and instance ID are used to identify where the desired service is located on the network and which zone controller (20_1, 20_2, 20_3, 20_4) provides the specific service. The instance ID is a unique identifier that identifies an instance of a specific service. Since there may be multiple instances sharing the same service ID, it serves to distinguish each one.

[0046] A SOME / IP service discovery message consists of a header, entries, and options.

[0047] As with all SOME / IP messages, the header contains basic message control information.

[0048] The entry includes a FindService, which is a message transmitted by the computing device (10) to find a specific service on the network, and an OfferService, which is a message notifying the network of a service provided by a zone controller (20_1, 20_2, 20_3, 20_4). Through the OfferService message, the computing device (10) can verify the service provided by the zone controller (20_1, 20_2, 20_3, 20_4).

[0049] The option includes endpoint information, which indicates the network of the device where the service is located.

[0051] FIG. 5 shows an explanatory diagram of the installation process of client software in an SDV-based in-vehicle network system (100) equipped with security functions in SOME / IP communication according to one embodiment.

[0053] Specifically, the computing device (10) may be configured to include an OTA (Over-the-Air) client module (11), a UCM (Update and Configuration Management) module (12), a client software module (13), and a security management table (14).

[0054] The OTA client module (11) is responsible for downloading a package of software for the client from the OTA server module (O) of the server (S).

[0055] The UCM module (12) is included in the Adaptive AUTOSAR Platform. Specifically, the UCM module (12) enables the download and installation of update files for client software via a wireless network. That is, the UCM module (12) receives and installs a package of client software from the OTA client module (11).

[0056] The client software module (13) is a module of client software that is installed, created, or updated by the UCM module (12).

[0058] The UCM module (12) obtains SOME / IP usage information, such as a service ID, instance ID, and client ID, through metadata regarding software information when installing client software. In addition, the UCM module (12) obtains the SOME / IP information from the metadata included in the package of client software and generates an authentication key string based on the SOME / IP information. The SOME / IP information may include a service ID, an instance ID, and a client ID.

[0059] The generation of an authentication key string may be performed by combining multiple data included in the relevant SOME / IP information and then combining random data. Alternatively, the generation of an authentication key string may be performed by combining multiple data included in the relevant SOME / IP information and then converting it using a hash function, or by combining multiple data included in the relevant SOME / IP information, then converting it using a hash function and then combining random data.

[0060] Alternatively, the authentication key string may be generated based on a value formed by combining at least one of a number or character received from a user when installing a package of client software and at least one of multiple data included in the corresponding SOME / IP information. That is, the authentication key string may be generated by converting the combined value using a hash function. For example, a value may be generated by combining a multi-digit number received from a user with an instance ID, and the combined value may be encrypted using a hash function to generate a multi-bit authentication key string.

[0062] Specifically, the UCM module (12) generates an authentication key string for each service ID, instance ID, and client ID included in the corresponding SOME / IP information and stores it in the security management table (14) in the form of a list. That is, the UCM module (12) stores the authentication key string along with the corresponding SOME / IP information in the security management table (14).

[0064] FIG. 6 shows an explanatory diagram of a security management table (14) according to one embodiment.

[0065] As can be seen from FIG. 6, authentication key strings can be stored in the security management table (14) for each service ID, instance ID, and client ID.

[0067] FIG. 7 is an explanatory diagram of the method of using a security management table (14) in an SDV-based in-vehicle network system (100) equipped with a security function in SOME / IP communication according to one embodiment.

[0068] Each of the multiple zone controllers (20_1, 20_2, 20_3, 20_4) can store or update the portion corresponding to the zone controller (20_1, 20_2, 20_3, 20_4) from the security management table (14) in the management table (22) for the corresponding zone controller through the central control unit (30). For example, each of the multiple zone controllers (20_1, 20_2, 20_3, 20_4) performs an update of the management table (22) for the corresponding zone controller when booting or when updating the security management table (14). Storing or updating the parts corresponding to the zone controllers (20_1, 20_2, 20_3, 20_4) from the security management table (14) in the management table (22) for the zone controllers may use the SOME / IP protocol through the SOME / IP transmission / reception module (21), but may also use a protocol other than the SOME / IP protocol.

[0069] Specifically, each of the multiple zone controllers (20_1, 20_2, 20_3, 20_4) stores or updates the corresponding list portion from the security management table (14) when a service ID among the lists stored in the security management table (14) corresponds to the corresponding zone controller (20_1, 20_2, 20_3, 20_4). That is, each of the multiple zone controllers (20_1, 20_2, 20_3, 20_4) obtains and stores the corresponding list from the security management table (14) when a service ID in the security management table (14) matches the service ID of the corresponding zone controller (20_1, 20_2, 20_3, 20_4).

[0071] In addition, when a service is searched by a client software module (13), the computing device (10) includes an authentication key string in the option field of the message of the corresponding SOME / IP and transmits the message through the central control unit (30) to the SOME / IP transmission / reception modules (21) of a plurality of zone controllers (20_1, 20_2, 20_3, 20_4). An example of a message transmitted by the computing device (10) when searching for a service is a find message.

[0072] Each of the multiple zone controllers (20_1, 20_2, 20_3, 20_4) compares the service ID, instance ID, client ID, and authentication key string included in the management table (22) for the zone controller with the service ID, instance ID, client ID, and authentication key string included in the SOME / IP message received by the SOME / IP transmission / reception module (21), and if they are the same, performs authentication processing and transmits the message to the computing device (10) through the central control unit (30).

[0074] The messages transmitted by the corresponding zone controllers (20_1, 20_2, 20_3, 20_4) to the computing device (10) may include not only offer messages for service search but also messages in which the SOME / IP protocol transmits and receives data over the network in an on-wire format.

[0075] That is, in an SDV-based in-vehicle network system (100) equipped with a security function in SOME / IP communication according to one embodiment, after the computing device (10) transmits an authentication key string included in an option field and the authentication process is completed by the corresponding zone controller (20_1, 20_2, 20_3, 20_4), a separate authentication process may not be required when transmitting and receiving messages in an on-wire format between the computing device (10) and the corresponding zone controller (20_1, 20_2, 20_3, 20_4) thereafter.

[0076] Specifically, the computing device (10) transmits a message of the corresponding SOME / IP containing an authentication key string included in an option field, and the corresponding zone controller (20_1, 20_2, 20_3, 20_4) determines whether the authentication key string, etc. are identical, and then the corresponding zone controller (20_1, 20_2, 20_3, 20_4) normally processes the transmission and reception of the message to the computing device (10).

[0077] That is, method calls, etc. are made possible after authentication is completed through the service search stage. For example, requests to the corresponding zone controllers (20_1, 20_2, 20_3, 20_4) are processed normally only for the client software module (13) of the computing device (10) for which authentication processing through the option field is completed during the service search stage.

[0079] Alternatively, in an SDV-based in-vehicle network system (100) equipped with a security function in SOME / IP communication according to one embodiment, even if authentication processing through an option field is completed during the service search stage, a separate authentication processing process may be required when transmitting and receiving messages in an on-wire format between the computing device (10) and the corresponding zone controllers (20_1, 20_2, 20_3, 20_4) thereafter.

[0080] At this time, the computing device (10) transmits a SOME / IP message in on-wire format to the corresponding zone controllers (20_1, 20_2, 20_3, 20_4) through the central control unit (30) by means of the client software module (13). Specifically, the computing device (10) may transmit the message through the central control unit (30) by including an authentication key string in the payload of the SOME / IP message. An example of such a message is a request message.

[0081] In addition, each of the multiple zone controllers (20_1, 20_2, 20_3, 20_4) can transmit a message to the computing device (10) via the central control unit (30) if the service ID, instance ID, client ID, and authentication key string included in the management table (22) for the zone controller are the same as the service ID, instance ID, client ID, and authentication key string included in the SOME / IP message received by the SOME / IP transmission / reception module (21). An example of such a message is a response message.

[0083] According to the SDV-based in-vehicle network system (100) equipped with security functions in SOME / IP communication of the embodiments disclosed in this specification, reliability of SOME / IP packets can be considered and applied from the time when client software is installed so as to ensure reliability between communication nodes.

[0084] Accordingly, according to the SDV-based in-vehicle network system (100) equipped with security functions in SOME / IP communication of the embodiments disclosed in this specification, SOME / IP security vulnerabilities can be compensated for, and by lightweighting the security functions without applying a separate security protocol, the degradation of process performance regarding interface processing can be prevented. That is, according to the SDV-based in-vehicle network system (100) equipped with security functions in SOME / IP communication of the embodiments disclosed in this specification, security is enhanced by applying security functions without performance degradation by processing security at the SOME / IP protocol level without applying existing security protocols for SOME / IP security.

[0086] As described above, according to the SDV-based in-vehicle network system (100) equipped with a security function in SOME / IP communication of the embodiments disclosed in this specification, by applying information for authentication to the option field or payload of the SOME / IP protocol message, it can be seen that it is possible to prevent unauthorized malicious applications from operating as SOME / IP clients and controlling electronic control units (E) inside the vehicle. Explanation of the symbols

[0087] 100: Vehicle internal network system 10: Computing device 20_1, 20_2, 20_3, 20_4_1, 20_2, 20_3, 20_4 : Zone controller 30: Central Control Unit 11: OTA Client Module 12: UCM Module 13: Client Software Module 14: Security Management Table 21 : SOME / IP Transceiver Module 22 : Management table for zone controller E: Electronic device

Claims

Claim 1 A vehicle internal network system comprises: a computing device for downloading and installing a package of client software; a plurality of zone controllers each controlling at least one electronic device within the vehicle; and a central control unit for mediating communication between the computing device and the plurality of zone controllers; wherein the computing device comprises: an OTA client module for downloading the package of client software; and a UCM module for receiving and installing the package of client software from the OTA client module. An internal vehicle network system comprising: a client software module, which is a module of the client software installed by the above UCM module; wherein the UCM module obtains SOME / IP information from metadata included in the package of the client software, generates an authentication key string for each service ID, instance ID, and client ID included in the SOME / IP information, and stores it in a security management table; each of the plurality of zone controllers stores or updates the part corresponding to the zone controller from the security management table in a management table for the zone controller; and the computing device transmits a message including the authentication key string in an option field of the SOME / IP message when searching for a service by the client software module, and each of the plurality of zone controllers transmits a message to the computing device if the service ID, instance ID, client ID, and authentication key string included in the management table for the zone controller are identical to the service ID, instance ID, client ID, and authentication key string included in the SOME / IP message received by the zone controller. Claim 2 delete Claim 3 delete Claim 4 delete Claim 5 delete Claim 6 delete Claim 7 In claim 1, the computing device transmits a message by means of the client software module, wherein the authentication key string is included in the payload of the message of the SOME / IP, in an internal automotive network system. Claim 8 An internal automotive network system according to claim 7, wherein each of the plurality of zone controllers transmits a message to the computing device in response if the service ID, instance ID, client ID, and authentication key string included in the management table for the zone controller are identical to the service ID, instance ID, client ID, and authentication key string included in the message of SOME / IP received by the zone controller. Claim 9 An internal vehicle network system according to claim 1, wherein the UCM module generates the authentication key string based on a value combining at least one of a number or character received from a user and at least one of a plurality of data included in the SOME / IP information.

Images