Device and method for performing authentication of on-demand service for vehicle

Abstract

To provide a device and a method for performing an authentication of an on-demand service for a vehicle.SOLUTION: There is provided a method performed in an integrated communication controller for performing an authentication of an on-demand service for a vehicle. The method includes the steps of: allowing a service authentication server to store a first option value relating to a service for a vehicle, the first option value being received from a TIF (Tool In Factory) device; acquiring or generating a private route secret key and a private route certificate; generating a device certificate and a device secret key signed by the private route secret key in each execution controller; generating a service token against the first option value by using the private route certificate and the private route secret key; and transmitting the generated service token, the private route certificate, and the device secret key to each execution controller.SELECTED DRAWING: Figure 4

Description

[Technical Field]

[0001] The present invention relates to an apparatus and method for performing authentication for a vehicle on-demand service. [Background technology]

[0002] Recently, the market for subscription services, which allow consumers to purchase and use the features they want for as long as they need them, has been gradually expanding. In response, vehicle subscription services are diversifying, moving beyond simple rental cars to include electric vehicle charging services, autonomous driving, and vehicle management. Furthermore, vehicle subscription services are gradually expanding to include connectivity services related to various internal functions, such as music and video streaming, route guidance, vehicle management, safety, and security.

[0003] In particular, on-demand vehicle services that provide specific optional specifications such as autonomous driving systems in the form of a subscription service have recently been fully introduced. The introduction of on-demand vehicle services will eliminate the inconvenience and financial burden of having to select unnecessary optional specifications in order to purchase the necessary options according to the purchase package when purchasing a vehicle, and will have the advantage of being able to select desired functions according to preference with a subscription service, as well as being able to temporarily disable or re-subscribe to functions, thereby meeting the diverse needs of consumers. Summary of the Invention [Problem to be solved by the invention]

[0004] An object of the present invention is to provide an apparatus and method for authenticating on-demand services for vehicles. The problems to be solved by the present invention are not limited to the problems described above, and other problems and advantages of the present invention not mentioned above can be understood from the following description and will be more clearly understood in the embodiments of the present invention. Furthermore, it will be understood that the problems and advantages to be solved by the present invention can be achieved by the means and combinations thereof set forth in the claims. [Means for solving the problem]

[0005] As a technical means for achieving the above technical object, there is provided a method, in an integrated communication control unit for authenticating an on-demand service for a vehicle, including the steps of: storing a first option value related to the vehicle service received from a TIF (Tool In Factory) device in a service authentication server; obtaining or generating a private root private key and a private root certificate; generating a device certificate and a device private key signed with the private root private key for each execution controller; generating a service token for the first option value using the private root certificate and the private root private key; and transmitting the generated service token, the private root certificate, and the device private key to each execution controller.

[0006] A second aspect of the present disclosure may provide a method, in an integrated communication control unit (CCU) for authenticating an on-demand service for a vehicle, including the steps of connecting a DM server with an encrypted secure communication (mTLS), obtaining a second option value related to the vehicle service received from the DM server using the encrypted secure communication, verifying a signature using one or more of the second option value, a signature, and a server certificate, decrypting the second option value using one or more of the second option value and a client private key, generating a service token based on the signature and the second option value, and transmitting the generated service token to each execution controller.

[0007] A third aspect of the present disclosure may provide a device that is an integrated communication control unit for authenticating an on-demand service for a vehicle, and that acquires a first option value related to the vehicle service received from a tool in factory (TIF) device, acquires or generates a private root private key and a private root certificate, generates a device certificate and a device private key signed with the private root private key for each execution controller, generates a service token for the first option value using the private root certificate and the private root private key, and transmits the generated service token, the private root certificate, and the device private key to each execution controller.

[0008] In addition, other methods and systems for implementing the present invention, and computer-readable recording media storing computer programs for executing the methods may also be provided.

[0009] Other aspects, features, and advantages, in addition to those described above, will become apparent from the following drawings, claims, and detailed description of the invention. [Effects of the Invention]

[0010] According to the above-described means for solving the problems of the present disclosure, the present disclosure allows an on-demand service for vehicles to be provided safely against hacking. Furthermore, even if an authentication system for an on-demand service for vehicles is hacked, the hacking will not be propagated to other vehicles, and the intrusion can be limited to the vehicle. [Brief explanation of the drawings]

[0011] [Figure 1] FIG. 1 is a diagram illustrating a device or system for performing authentication for an on-demand service for a vehicle according to an embodiment. [Figure 2] FIG. 2 is a diagram illustrating a device or system for performing authentication for an on-demand service for a vehicle according to an embodiment. [Figure 3] FIG. 3 is a diagram illustrating a device or system for performing authentication for an on-demand service for a vehicle according to an embodiment. [Figure 4] FIG. 4 is a flowchart showing the operation of the first use case according to one embodiment. [Figure 5] FIG. 5 illustrates a first and a second embodiment of the first use case described above, according to an embodiment. [Figure 6] FIG. 6 illustrates a first and a second embodiment of the first use case described above, according to an embodiment. [Figure 7] FIG. 7 is a block diagram illustrating the operation of the second use case according to one embodiment. [Figure 8] FIG. 8 is a flowchart illustrating the operation of the second use case according to one embodiment, divided by operating entity. [Figure 9] FIG. 9 is a flow chart illustrating a method for generating a service token according to one embodiment. [Figure 10A] FIG. 10A is a diagram for explaining the generation and verification of a service token. [Figure 10B] FIG. 10B is a diagram for explaining the generation and verification of a service token. DETAILED DESCRIPTION OF THE INVENTION

[0012] The advantages and features of the present invention, as well as methods for achieving them, will become clearer with reference to the embodiments described in detail in conjunction with the accompanying drawings. However, the present invention is not limited to the embodiments described below, and may be embodied in various different forms, and should be understood to include all modifications, equivalents, and alternatives within the spirit and technical scope of the present invention. The embodiments described below are provided to fully disclose the present invention and to fully convey the scope of the invention to those skilled in the art to which the present invention pertains. In describing the present invention, if it is determined that a detailed description of related known technology may hinder the gist of the present invention, such detailed description will be omitted.

[0013] The terms used in this application are merely used to describe specific embodiments and are not intended to limit the present invention. The singular expressions include the plural expressions unless the context clearly dictates otherwise. In this application, terms such as "comprise" or "have" specify the presence of features, numbers, steps, operations, components, parts, or combinations thereof described herein, and should be understood not to preclude the presence or additional possibility of one or more other features, numbers, steps, operations, components, parts, or combinations thereof.

[0014] Some embodiments of the present disclosure may be expressed in terms of functional blocks and various processing steps. Some or all of these functional blocks may be implemented in various hardware and / or software configurations that perform specific functions. For example, the functional blocks of the present disclosure may be implemented by one or more microprocessors or by circuit configurations for a given function. Furthermore, for example, the functional blocks of the present disclosure may be implemented in various programming or scripting languages. The functional blocks may be implemented by algorithms executed by one or more processors. Furthermore, the present disclosure may employ conventional techniques for electronic configuration, signal processing, and / or data processing. Terms such as "mechanism," "element," "means," and "component" may be used broadly and are not limited to mechanical or physical configurations.

[0015] Furthermore, connecting lines or connecting members between components shown in the drawings are merely exemplary of functional and / or physical or circuit connections, and in an actual device, connections between components may be represented by various alternative or additional functional, physical, or circuit connections.

[0016] In the following, "vehicle" can mean any kind of transport means having a motor and used to move people or goods, such as a car, bus, motorcycle, scooter or truck.

[0017] The present disclosure will now be described in detail with reference to the accompanying drawings.

[0018] 1 to 3 are diagrams illustrating an apparatus or system for performing authentication for an on-demand service for a vehicle according to an embodiment. The following description will be given with reference to FIGS. 1 to 3.

[0019] Referring to FIG. 1, an environment for performing authentication of an on-demand service for a vehicle includes a vehicle 10, a network 20, and an external device 30. According to one embodiment, the vehicle 10 may be an autonomous vehicle equipped with an autonomous driving device. The vehicle 10 may further include an integrated communication control unit (CCU) for providing the on-demand service, an execution controller for driving the service, and a CAN or Ethernet network device for communication between devices within the vehicle. This will be further described in the description of FIGS. 2 and 3.

[0020] Furthermore, the network 20 is a network that connects the internal and external devices 30 of the vehicle 10, and the communication method is not limited thereto, and may include one or more of a communication method that uses a communication network (for example, a mobile communication network, a wired Internet, a wireless Internet, or a broadcasting network) that the network 20 can include, but is not limited to, a security network such as TLS (Transport Layer Security), or a diagnostic network such as UDS (Unified Diagnostic Service).

[0021] The external device 30 may be an external device that must be connected to the vehicle 10 to provide on-demand services, such as various servers or diagnostic devices. In particular, the external device 30 may be embodied as a computer device or multiple computers that communicate with the vehicle 10 via the network 20 and provide instructions, code, files, content, services, etc.

[0022] Referring to Fig. 2, a system 100 for authenticating an on-demand service for a vehicle is shown. In the following description, for convenience of explanation, the system 100 for authenticating an on-demand service for a vehicle may be referred to as a service authentication system 100. Fig. 3 is a diagram showing the service authentication system 100 in more detail.

[0023] Meanwhile, according to one embodiment, the on-demand vehicle service is a function that allows consumers to selectively purchase software functions according to their needs and is installed in a vehicle, allowing consumers to customize desired vehicle functions whenever they want. A vehicle equipped with the on-demand vehicle service is also called an SDV (Software Defined Vehicle). According to one embodiment, a consumer who purchases an SDV vehicle can use the on-demand vehicle service to purchase and activate desired functions for a set period (permanently or for a specific period).

[0024] Furthermore, since the on-demand service for vehicles according to one embodiment is executed based on PKI (Public Key Infrastructure) in the security domain of the integrated communication controller, the service can be provided safely against hacking, which can be realized by the service authentication system 100 of the present invention.

[0025] Furthermore, according to the service authentication system 100 according to one embodiment, security within the unified communication controller can be applied to on-demand products purchased by a user for permanent use with a one-time payment or for subscription for a specific period. As a result, even if the service authentication system 100 is hacked, it can be configured so that the intrusion occurs only in the SDV and not in other SDVs.

[0026] Continuing to refer to FIGS. 2 and 3, the service authentication system 100 may include a DM (Database Management) server 110, an integrated communication controller 120, an execution controller 130, a TIF facility 150, and a purchase server 140.

[0027] First, the DM server 110 can be a server that is connected to the purchase server 140 (described later) and the service agent 121 in the integrated communication controller 120 via mTLS (mutual TLS) and manages device information for driving on-demand services in the vehicle in a database.

[0028] More specifically, the DM server 110 includes an MQTT (Message Queuing Telemetry Transport) manager 111. The MQTT manager 111 is connected to the purchasing server 140 and the service agent 121 of the unified communication controller 120 via mTLS, and can transmit setting information (or service option values) for each on-demand device to the service agent 121 of the unified communication controller 120.

[0029] Although not shown in the figure, the DM server 110 may have root certificates, server certificates, and server private keys as stored values. More specifically, the root certificate is a public certificate issued by a root certification authority, which is the highest certification authority in the public key infrastructure structure, and can be injected from the TIF facility 150. Furthermore, the server certificate is an intermediate certificate signed with a root private key generated from the root certification authority. Furthermore, the server private key is a private key generated by the DM server 110 and can be used to generate the above-mentioned server certificate.

[0030] Furthermore, the MQTT manager 111 of the DM server 110 can use mTLS (mutual Transport Layer Security) as an encryption protocol when communicating with the unified communication controller 120 and the purchasing server 140. According to one embodiment, mTLS verifies that the MQTT manager 111 and the service agent 121 have the correct private keys and verifies that they are legitimate communication parties. More specifically, mTLS allows communication to be linked only when each communication party is verified and trusted after exchanging each other's certificates to certify all information between the service agent 121 of the unified communication controller 120 and the MQTT manager 111 of the DM server 110.

[0031] Next, the unified communication controller 120 is a control device for linking functions and transmitting data inside and outside the vehicle. More specifically, the unified communication controller 120 may include a service agent 121 and a service authentication server 122, as shown in Fig. 3. The service agent 121 operates in a normal world of the unified communication controller 120 and transmits a service token, a device certificate, and a device private key transmitted from the service authentication server 122 to each execution controller 130.

[0032] Next, the service authentication server 122 operates in the secure world of the unified communication controller 120 , generates a service token, a device certificate, and a device private key, and transmits them to the service agent 121 .

[0033] In addition, the unified communication controller 120 can obtain or generate one or more of a root certificate, a client private key, a client certificate, a private root private key, a private root certificate, a device certificate, and a device private key.

[0034] More specifically, the root certificate is a public certificate issued by a root certification authority, which is the highest certification authority in the public key infrastructure structure as described above, and can be obtained from the DM server 110 or the TIF facility 150.

[0035] The client private key is a key generated by the DM server 110, used to generate a client certificate, and can be obtained from the TIF facility 150. The client certificate is also an intermediate certificate generated by the DM server 110, signed with the root private key, and used, and can be obtained from the TIF facility 150.

[0036] The private root private key is a key issued by the service authentication server 122 and can be used to generate a private root certificate, which is a private root Certificate Authority (CA) certificate issued by the service authentication server 122.

[0037] Next, the execution controller 130 is an in-vehicle device for driving the on-demand service for the vehicle purchased by the user. In the following description, the execution controller 130 may be used to refer to the first to Nth execution controllers, which are execution controllers in the vehicle.

[0038] The execution controller 130 may include a service manager 131, which may store a service token, a device certificate, and a device private key in secure storage.

[0039] First, the service manager 131 receives a service token, a certificate of the unified communication controller 120, and a device private key from the service agent 121 of the unified communication controller 120. The service token is a token issued by the service authentication server 122 of the unified communication controller 120, and service setting data can be encrypted and stored in a payload and signed with a private root private key. The private root certificate is a certificate of the unified communication controller 120 issued by the service authentication server 122 and can be used to verify the digital signature of the service token. The device private key is a private key issued for each execution controller 130 by the service authentication server 122 of the unified communication controller 120 and can be used to decrypt the service setting data in the service token.

[0040] In addition, the TIF equipment 150 is a facility that is connected only once to a vehicle produced in a process and injects the root certificate, client certificate, and client private key issued by the DM server 110 into the secure storage of the secure world of the integrated communication controller 120.

[0041] According to one embodiment, a security asset refers to data, functions, and resources to be protected, and multiple security assets can be identified by a system model and a use case. Also, security objectives are divided into integrity, confidentiality, authenticity, availability, and freshness, and security attributes that can exist in each asset can be identified.

[0042] According to one embodiment, the identification data (configuration data) of the unified communication controller 120, which is a security asset, is on-demand service option information for a vehicle stored in the unified communication controller 120 and may have the security attribute of integrity. Furthermore, the firmware of the unified communication controller 120, which is a security asset, is compiled firmware code running on the unified communication controller 120 and may have the security attributes of confidentiality and integrity. Furthermore, the backend communication, which is a security asset, is data transmitted and received for service purchase and communication with the DM server 110 and may have the security attributes of confidentiality, authenticity, recency, and availability. Furthermore, the cryptographic materials, which are a security asset, are information on keys or certificates used for encryption / decryption of service token issuance in the unified communication controller 120 and may have the security attributes of confidentiality and integrity.

[0043] An on-demand service authentication service according to an embodiment of the present invention may have one or more security requirements, and each security requirement may correspond to one or more security threats. The security threats corresponding to the first to fifth security requirements according to an embodiment are as shown in Table 1 below. [Table 1]

[0044] More specifically, the first security requirement (SRV01) requires that unpurchased service option values ​​must not be activated through the theft or tampering of firmware in the unified communication controller 120, memory dump, etc. The second security requirement (SRV02) requires that the integrity of service option information stored in the unified communication controller 120 must be ensured so that it is not tampered with. The third security requirement (SRV03) requires that communication with the DM server 110 must be secure against man-in-the-middle attacks or session hijacking attacks. The fourth security requirement (SRV04) requires that service option values ​​transmitted from the DM server 110 must not be tampered with. The fifth security requirement (SRV05) requires that unauthorized entities (OTA diagnostic devices) must not be able to access the execution controller 130. Meanwhile, in the following description, for convenience of explanation, the first to fifth security requirements may be referred to by their respective IDs.

[0045] Meanwhile, according to one embodiment, there may be three use cases of the service authentication system. The first use case (UC01) is when a customer purchases an on-demand service for a vehicle as a pre-purchase option before shipping the vehicle, and the vehicle's service setting information may be set through a diagnostic device on the factory TIF line. The second use case (UC02) is when a customer purchases an on-demand service for a vehicle after shipping the vehicle, and when the customer purchases the service after shipping the vehicle, the vehicle's service setting information may be set through the DM server 110. The third use case (UC03) is when an on-demand service is activated or deactivated when the vehicle is started after shipping the vehicle, and each execution controller 130 may be activated or deactivated according to the latest service setting information.

[0046] Next, the operation procedure of the first use case (UC01) will be described in more detail. First, the TIF facility 150 injects a root certificate, a client certificate, and a client private key into the security domain for establishing an mTLS connection with the DM server 110 via the service agent 121 of the unified communication controller 120.

[0047] FIG. 4 is a flowchart showing the operation of the first use case (UC01) according to one embodiment.

[0048] Figure 4 is a flowchart described assuming that the unified communication controller 120 is the subject of the operation, but in an alternative embodiment of the present invention, the subject of each operation can be the TIF equipment 150, the service agent 121 and service authentication server 122 of the unified communication controller 120, and the service manager 131 of the execution controller 130.

[0049] More specifically, the root certificate, client certificate, and client private key for mTLS connection to the DM server 110 are obtained from the TIF facility 150 and stored in the secure storage (401). At this time, the security requirement ID in step 401 is SRV05.

[0050] Next, the service agent 121 of the integrated communication controller 120 acquires the service advance purchase option value (service option value) for the vehicle and the sales system from the TIF facility 150 (402). At this time, the security requirement IDs in step 402 are SRV02, SRV03, and SRV05. The service advance purchase option value can also be referred to as the first option value.

[0051] Meanwhile, in step 403, the DM server 110 can also obtain the service advance purchase option value in the vehicle and sales system from the TIF facility 150 and store it in the database. At this time, the security requirement ID is SRV03.

[0052] Next, the service agent 121 of the unified communication controller 120 stores the service advance purchase option value for the vehicle transmitted from the TIF facility 150 in a secure storage in the secure world (403). In addition, the service authentication server 122 can obtain and store the service advance purchase option value for the vehicle service, i.e., the first option value. In this case, the security requirement ID is SRV01, SRV04, or SRV05.

[0053] Next, the service authentication server 122 may obtain or generate a private root secret key (root key) and a private root certificate of the unified communication controller 120 in the security domain (404). The private root secret key may be a secret key for issuing a service token.

[0054] Next, the service authentication server 122 generates a device certificate and a device key signed with the private root private key for each execution controller 130 in the security domain (405).

[0055] Next, the service authentication server 122 issues a service token for the service pre-purchase option value using the private root certificate and the private root secret key (406). Furthermore, the service authentication server 122 transmits the service token, the private root certificate, and the device secret key generated for each execution controller 130 in the security domain to the service agent 121.

[0056] Next, the service agent 121 transmits the service token, the private root certificate, and the device private key transmitted from the security domain to each execution controller 130 (407). At this time, each execution controller 130 can store the service token, the device certificate, and the device private key transmitted from the service agent 121 in its own security storage.

[0057] On the other hand, the security requirement IDs in steps 404 to 408 described above are SRV01, SRV02, and SRV05.

[0058] 5 and 6 illustrate a first and second embodiment, respectively, of the first use case described above, according to one embodiment.

[0059] 5 and 6 show a first embodiment (UC01-1) and a second embodiment (UC01-2), respectively, in which the operating entities that perform each operation of the first use case (UC01) are different. The following embodiments of Fig. 5 and Fig. 6 can show that the operations of the first use case (UC01) are performed by the TIF facility 150, the service agent 121 and the service authentication server 122 of the unified communication controller 120, and the service manager 131 of the execution controller 130.

[0060] First, Figure 5 shows a block diagram of the operation of the first embodiment (UC01-1) in which the service authentication server 122 plays a major role rather than the service agent 121 of the integrated communication controller 120 in the first use case (UC01) in which an on-demand service for a vehicle is purchased as an advance purchase option before the vehicle is shipped.

[0061] Referring to FIG. 5, first, the TIF facility 150 injects a first option value (service advance purchase option value as service data) into the service agent 121 of the unified communication controller 120 (501).

[0062] Next, the service agent 121 stores the transmitted first option value in a database and transmits it to the service authentication server 122 in the security domain (502).

[0063] Next, the service agent 121 requests the service authentication server 122 to generate a private root key (503). In one embodiment, the private root key may be composed of a private root private key and a private root certificate (which may also be referred to as a private root public key). Furthermore, the private root key may be an asymmetric key, stored in the unified communication controller 120, and generated only in one pair.

[0064] Next, the service authentication server 122 generates a private root private key (504) and generates a private root certificate (505).

[0065] Next, the service authentication server 122 generates device keys for each linked device. According to one embodiment, the device keys may be composed of a device private key and a device certificate (which may also be referred to as a device public key). Furthermore, the device keys may be characterized in that asymmetric keys are used, several pairs are generated, and only one pair is kept for each execution controller. That is, the service authentication server 122 generates a device private key for each execution controller 130 (506) and generates a device certificate signed with the private root private key (507).

[0066] The service authentication server 122 then communicates the private root certificate to the service agent 121 (508).

[0067] Next, the service agent 121 requests device information from the service authentication server 122 (509), and in response, the service authentication server 122 generates a service token (510).

[0068] Next, the service authentication server 122 sends the generated service token and device private key to the service agent 121 (511).

[0069] Next, the service agent 121 sends the service token, the private root certificate, and the device private key to each execution controller 130 to the service manager 131 created for each execution controller 130 (512).

[0070] Next, the service manager 131 of each execution controller 130 stores the private root certificate and the device private key in the security storage within each execution controller 130 (513, 514). The service manager 131 also verifies the service token (515).

[0071] 6 is a block diagram illustrating the operation of a second embodiment (UC01-2) in which the service agent 121 of the unified communication controller 120 plays a more important role than the service authentication server 122 in the first use case (UC01) in which the vehicle on-demand service is purchased as a pre-purchase option before the vehicle is shipped. The second embodiment (UC01-2) of the first use case is a modified version of the first embodiment (UC01-1), and therefore overlapping or corresponding configurations will not be described.

[0072] Referring to FIG. 6, first, the TIF facility 150 injects a first option value (service advance purchase option value) into the service agent 121 of the unified communication controller 120 (601).

[0073] Next, the service agent 121 stores the transmitted first option value in a database and transmits it to the service authentication server 122 in the security domain (602).

[0074] Next, the service agent 121 requests the service authentication server 122 to generate a private root key (603).

[0075] Next, the service authentication server 122 generates a private root private key (604) and generates a private root certificate (605).

[0076] Next, the service authentication server 122 communicates the generated private root certificate to the service agent 121 (606).

[0077] Next, the service authentication server 122 receives device key generation requests from the service agent 121 (607) for each execution controller. Furthermore, upon receiving the device key generation requests, the service authentication server 122 generates a device private key for each execution controller 130 (608) and generates a device certificate signed with the private root private key (609).

[0078] Next, the service agent 121 generates a service token (610).

[0079] Next, the service authentication server 122 transmits the generated device private key to the service agent 121 (611).

[0080] Next, the service agent 121 sends the service token, the private root certificate, and the device private key to each execution controller 130 to the service manager 131 created for each execution controller 130 (612).

[0081] Next, the service manager 131 of each execution controller 130 stores the private root certificate and the device private key in the security storage within each execution controller 130 (613, 614). The service manager 131 also verifies the service token (615).

[0082] FIG. 7 is a block diagram illustrating the operation of the second use case according to one embodiment.

[0083] That is, FIG. 7 is a flowchart showing a case where purchase information is updated after shipment as a second use case (UC02) according to one embodiment.

[0084] First, the DM server 110 stores the post-shipment service purchase option value acquired from the purchase server 140 in the database. In the following description, the post-shipment service purchase option value may also be referred to as the second option value. At this time, the security requirement ID is SRV02.

[0085] Next, referring to FIG. 7, the service agent 121 establishes encrypted security communication (mTLS) through mutual authentication between the DM server 110 and the service agent 121 in the unified communication controller 120 (701).

[0086] Next, the service agent 121 acquires the post-shipment service purchase option value from the DM server 110 using mTLS communication (702). At this time, the security requirement IDs in steps 701 and 702 are SRV03 and SRV04.

[0087] Next, the service agent 121 communicates the post-shipment service purchase option value to the service authentication server 122 within the security domain (703). In this case, there may be no security requirements applied between the service agent 121 and the service authentication server 122.

[0088] Next, the service authentication server 122 generates a service token (704). The service authentication server 122 also transmits the generated service token to the service agent 121, and the service agent 121 transmits the transmitted service token to each execution controller 130 (705). At this time, the security requirement IDs are SRV02 and SRV05.

[0089] Next, the execution controller 130 stores the service tokens transmitted from the unified communication controller 120 in the security storage within each execution controller 130. At this time, the security requirement IDs are SRV01, SRV02, SRV03, SRV04, and SRV05.

[0090] FIG. 8 is a flowchart illustrating the operation of the second use case according to one embodiment, divided by operating entity.

[0091] 8, unlike Figures 5 and 6, the second use case (UC02) includes the DM server 110 as the operating subject instead of the TIF facility 150. As described above, the first use case (UC01) is for connecting to the TIF line at the factory before shipping the vehicle and setting the service option values ​​of the vehicle, whereas the second use case (UC02) is for setting the service option values ​​of the vehicle via the DM server 110 when a user purchases an on-demand service product after shipping the vehicle.

[0092] More specifically, referring to FIG. 8, first, the DM server 110 stores the post-shipment service purchase option value (service data) acquired by the purchasing server 140 in a database (801), and then transmits the service data to the service agent 121 (802).

[0093] Next, the service agent 121 transmits the acquired service data to the service authentication server 122 (803).

[0094] Next, the service authentication server 122 receives the signature verification request including the service data and the signature (804), and executes a signature verification procedure including the service data, the signature, and the server certificate (805).

[0095] Next, the service authentication server 122 receives (806) a storage request for the on-demand service data including the device ID and the on-demand service data, and performs (807) a decryption procedure for the on-demand service data including the on-demand service data and the client private key.

[0096] Next, the service agent 121 generates a service token (808).

[0097] Next, the service agent 121 sends the generated service token to the service manager 131 of the execution controller 130 (809), and the execution controller 130, upon receiving the service token, verifies the service token (810).

[0098] Next, the third use case (UC03) is a case where the on-demand service is activated or deactivated when the vehicle is started after shipping, as described above. In the third use case (UC03), the on-demand service function of each execution controller 130 can be activated or deactivated according to the latest on-demand service setting information.

[0099] More specifically, in the third use case (UC03), first, the digital signature of the service token is checked using a private root certificate stored in the security storage of each execution controller 130 to confirm whether the service token has been tampered with. Next, the AES key stored in the header of the service token is decrypted using a device private key stored in the security storage of each execution controller 130, and the encrypted payload data of the service token is decrypted using the obtained AES key to determine whether each execution controller 130 is turned on or off. In this case, the security requirement IDs are SRV01, SRV02, SRV03, SRV04, and SRV05.

[0100] As described above, according to one embodiment, the service authentication system generates a service token for authentication, and service data (service option values) are encrypted and stored in the payload of the service token. Furthermore, the service token can be digitally signed with a private root key. The structure of the service token, its generation method, and its verification (authentication) method will be described in more detail below.

[0101] A service token structure consists of three fields: a header, a payload, and a trailer. First, the header of a service token can hold information about the AES key, payload length, AES key encryption algorithm (e.g., AES-256 CBC), payload encryption algorithm (e.g., RSAES-OAEP 2048), and signature generation algorithm (e.g., RSASSA-PSS 2048). In this case, the AES key can be encrypted with the device certificate and decrypted with the device private key.

[0102] Furthermore, the payload of the service token can hold information of service data, where the service data can be encrypted and decrypted with an AES key, and the trailer of the service token can include information of a signature for the header and payload, where the signature can be generated with a private root private key and authenticated with a private root certificate.

[0103] FIG. 9 is a flow chart illustrating a method for generating a service token according to one embodiment.

[0104] According to one embodiment, service token generation may be performed by the unified communication controller 120. According to one embodiment, in the first embodiment of the first use case (UC01-1), the service token may be generated by the service authentication server 122, and in the second embodiment of the first use case (UC01-2), the service token may be generated by the service agent 121.

[0105] The following description will focus on an example in which a service token is generated by the service authentication server 122 according to the first embodiment (UC01-1) of the first use case.

[0106] First, an AES symmetric key is generated in the security domain, and the stored service pre-purchase option (service data) is AES encrypted and stored in a payload field within the service token (901). According to one embodiment, the AES key is a symmetric key, and can be randomly generated each time a service token is generated.

[0107] Next, the AES symmetric key previously generated in the device certificate in the security domain is encrypted with a public key algorithm (RSA according to one embodiment) and added to the service token header (902).

[0108] Next, the service token is digitally signed with the private root private key in the security domain (903).

[0109] 10A and 10B are diagrams for explaining the generation and verification of a service token, respectively.

[0110] First, FIG. 10A is a diagram illustrating the steps in the service token generation process and which data is used or generated in each step.

[0111] First, service data is generated (10a-1).

[0112] Next, the service data is encrypted (10a-2), where the service data generated in step 10a-1 is encrypted using a symmetric key algorithm (in one embodiment, an AES key) to generate encrypted service data.

[0113] Next, the AES key is encrypted (10a-3). At this time, the AES key is encrypted with the device certificate (device public key) to generate an encrypted AES key.

[0114] Next, a signature is generated (10a-4). At this time, the signature can be generated using the private root private key for the encrypted AES key generated in step 10a-3 and the encrypted service data generated in step 10a-2.

[0115] Next, a service token is generated (10a-5). At this time, the service token may have a header, a payload, and a trailer field. The header field may include encrypted AES key information, the payload field may include encrypted service data, and the trailer field may include signature information.

[0116] Continuing, FIG. 10B is intended to explain the steps in the service token verification (authentication) process and what data is used or generated at each step.

[0117] First, a service token is obtained (10b-1). As described above in the description of Fig. 10A, the header field of the obtained service token can include encrypted AES key information, the payload field can include encrypted service data, and the trailer field can include signature information.

[0118] Next, the signature is verified (10b-2). The signature can be verified using the encrypted AES key and the private root certificate (public key) for the encrypted service data.

[0119] Next, the AES key is decrypted (10b-3). At this time, the encrypted AES key is decrypted with the device private key, and a decrypted AES key can be generated.

[0120] Next, the service data is decrypted (10b-4). At this time, the encrypted service data can be decrypted using the decrypted AES key.

[0121] Next, the decrypted service data is obtained (10b-5).

[0122] Embodiments of the present invention may be embodied in the form of a computer program executable by various components on a computer, and such a computer program may be recorded on a computer-readable medium, which may include magnetic media such as hard disks, floppy disks, and magnetic tapes, optical media such as CD-ROMs and DVDs, magneto-optical media such as floptical disks, and hardware devices specially configured to store and execute program instructions, such as ROMs, RAMs, and flash memories.

[0123] Meanwhile, the computer program may be specially designed and constructed for the present invention, or may be one that is well known and available to those skilled in the art of computer software. Examples of the computer program include not only machine language code such as that produced by a compiler, but also high-level language code that can be executed by a computer using an interpreter, etc.

[0124] According to one embodiment, methods according to various embodiments of the present disclosure may be provided in a computer program product. The computer program product may be traded as a commodity between a seller and a buyer. The computer program product may be distributed in the form of a device-readable storage medium (e.g., a compact disc read-only memory (CD-ROM)) or may be distributed online (e.g., downloaded or uploaded) via an application store (e.g., Play Store™) or directly between two user devices. In the case of online distribution, at least a portion of the computer program product may be at least temporarily stored in or temporarily generated on a machine-readable storage medium, such as the memory of a manufacturer's server, an application store server, or an intermediary server.

[0125] Unless otherwise expressly stated or contrary to the order of steps constituting the method of the present invention, the steps may be performed in any suitable order. The present invention is not necessarily limited to the order of the steps described. The use of all examples or exemplary terms (e.g., etc.) in the present invention is merely for the purpose of explaining the present invention in detail, and the scope of the present invention is not limited by such examples or exemplary terms unless otherwise limited by the claims. Furthermore, those skilled in the art will understand that various modifications, combinations, and variations may be made depending on design conditions and factors within the scope of the appended claims or their equivalents.

[0126] Therefore, the concept of the present invention should not be limited to the above-described embodiments, and it can be said that not only the scope of the claims described below, but also all scopes equivalent to or modified equivalently from the scope of the claims belong to the scope of the concept of the present invention.

Claims

1. A communication control unit for authenticating an on-demand service for a vehicle, comprising: storing a first option value for the vehicle service received from the Tool In Factory (TIF) device in a service authentication server; Obtaining or generating a private root private key and a private root certificate; generating a device certificate and a device private key for each execution controller, the device certificate and device private key being signed with the private root private key; generating a service token for the first option value using the private root certificate and the private root private key; transmitting the generated service token, the private root certificate, and the device private key to each of the execution controllers; A method comprising:

2. The method of claim 1 , wherein the private root private key and the private root certificate are generated within a secure world of the unified communications controller.

3. The method of claim 2 , wherein the service token is generated within a normal world of the unified communications controller.

4. The method of claim 1 , wherein the private root private key and private root certificate are generated at the service authentication server of the unified communications controller.

5. The method of claim 4 , wherein the service token is generated within a normal world of the unified communications controller.

6. The step of generating a service token includes: generating an AES (Advanced Encryption Standard) symmetric key, AES-encrypting the first option value and storing the value in a payload field within the service token; encrypting the AES symmetric key to RSA with the device certificate and adding it to a header field in the service token; digitally signing the service token with the private root private key; The method of claim 1 , comprising:

7. A communication control unit for authenticating an on-demand service for a vehicle, comprising: Connecting the DM server to an encrypted secure communication (mTLS); obtaining a second option value related to a vehicle service received from the DM server using the encrypted secure communication; verifying the signature using one or more of the second option value, a signature, and a server certificate; decrypting the second option value using one or more of the second option value and a client private key; generating a service token based on the signature and the second option value; transmitting the generated service token to each execution controller; A method comprising:

8. As an integrated communication control unit (CCU) for authenticating on-demand services for vehicles, obtaining a first option value for a vehicle service received from a Tool In Factory (TIF) device; Obtaining or generating a private root private key and a private root certificate; generating a device certificate and a device private key signed with the private root private key for each execution controller; generating a service token for the first option value using the private root certificate and the private root key; The apparatus transmits the generated service token, the private root certificate, and the device private key to each of the execution controllers.

9. A computer-readable recording medium having recorded thereon a program for executing the method of claim 1 on a computer.

Images