Mobility-based on-demand feature subscription security system

Abstract

The present invention relates to a mobility-based on-demand function subscription security system, comprising a server, wherein the server comprises: a storage unit for storing function subscription information for determining the activation or deactivation of a function of an electronic control unit within a vehicle; a control unit for performing operations to verify the integrity of a function token using the vehicle's unique identification information, function subscription information, and received post-quantum cryptography-based public key data; and a communication unit for receiving function token data generated in a communication section between the vehicle and the server.

Description

Technology Field

[0001] The present invention relates to a mobility-based on-demand function subscription security system. Background Technology

[0002] With the recent widespread adoption of technology that software-controlled the functions of in-vehicle Electronic Control Units (ECUs), vehicle manufacturers or service providers are introducing on-demand feature subscription methods that enable or disable specific functions based on user selection. In this on-demand subscription method, function tokens determining whether to activate a function are exchanged through communication between the vehicle and the server, and the operating state of the ECU changes according to the information contained in the said function token.

[0003] In conventional function subscription systems, configurations verifying the validity of function tokens using symmetric-key based cryptography or existing public-key cryptography have been generally applied. However, these cryptographic methods have limitations, such as the possibility of key exposure during long-term use, issues with token reuse due to communication retransmission, and insufficient verification of the combination between vehicle identification information and function subscription information. Furthermore, concerns have been raised that the security of existing public-key cryptography may degrade, particularly in quantum computing environments.

[0004] Furthermore, in conventional technology, function activation is often determined solely based on the integrity verification results of function tokens received at the time of vehicle startup or function request. This leads to vulnerabilities to man-in-the-middle attacks or control signal tampering, as the same function token may be used repeatedly due to network delays or retransmissions, or control commands following activation are transmitted in plaintext or via fixed keys. Consequently, there is a risk of unauthorized function activation, function state inconsistencies, or abnormal operation of vehicle functions. The problem to be solved

[0005] The present invention is intended to solve the aforementioned problems by storing function subscription information for determining the activation or deactivation of a function of an electronic control unit within a vehicle in a storage unit of a server, and by combining the vehicle's unique identification information, function subscription information, and received post-quantum cryptography-based public key data to verify the integrity of the function token, thereby ensuring that the function token is treated as a verification target dependent on the vehicle and subscription status rather than as simple identification information.

[0006] By applying post-quantum cryptography-based integrity verification using Kyber-based or Dilithium-based parameter verification formulas, the potential for long-term security degradation, which was an issue in existing public-key cryptography, is structurally resolved, and functional subscription security can be maintained even in future quantum computing environments,

[0007] After the integrity verification of the function token is completed, a new function session key is generated by combining a temporary random number generated by the in-vehicle function subscription module with a random number received from the server, and an encrypted control command for the function activation signal is generated using the said function session key and transmitted to the vehicle gateway. Through this, the process of determining function activation and transmitting the actual ECU control command is protected by being separated into session units rather than relying on a single fixed key, thereby effectively reducing the risk associated with the reuse or tampering of the control signal.

[0008] Consequently, by linking function token verification, session key renewal, and encrypted control command transmission throughout the entire process from vehicle ignition to the transmission of function activation commands, this invention provides a mobility-based on-demand function subscription security system that structurally prevents issues such as unauthorized function activation, function token reuse, and tampering with control signals—problems inherent in conventional technology—and substantially enhances security reliability in a mobility-based on-demand function subscription environment. means of solving the problem

[0009] A mobility-based on-demand function subscription security system according to one embodiment of the present invention comprises a server, wherein the server includes: a storage unit for storing function subscription information for determining the activation or deactivation of a function of an electronic control unit within a vehicle; a control unit for performing operations to verify the integrity of a function token using unique identification information of the vehicle, function subscription information, and received post-quantum cryptography-based public key data; and a communication unit for receiving function token data generated in a communication section between the vehicle and the server.

[0010] The control unit receives function token data through the communication unit at the time the vehicle starts, and verifies the integrity of the function token by combining the vehicle identification information and function subscription information stored in the storage unit with the electronic signature and key derivative value included in the function token and substituting them into a post-quantum cryptography-based verification formula, wherein the post-quantum cryptography-based verification formula is configured to use at least one of a Kyber-based parameter verification formula or a Dilithium-based parameter verification formula, and generates a function activation signal to activate the function corresponding to the function subscription information if the verification result according to the post-quantum cryptography-based verification formula is normal, and generates a function invalidation signal to maintain the corresponding function in a locked state if the verification result according to the post-quantum cryptography-based verification formula is abnormal.

[0011] The above control unit is characterized by additionally including the step of, after the integrity verification of the function token is completed, generating a new function session key according to the post-quantum-based session key update function SK′ = H(r_v ∥ r_s ∥ vehicle identification information ∥ function subscription information) using a temporary random number r_v generated in the function subscription module within the vehicle and a random number r_s received from the server, and generating an encrypted control command for a function activation signal using the function session key and transmitting it to the vehicle gateway.

[0012] The control unit transmits at least one of a function activation signal or a function deactivation signal generated in a protected state by the function session key to a Software-Defined Vehicle-based gateway, determines a function policy condition using current function status data received from the gateway, wherein the function status data is configured to include whether the function is activated, a device load value, and a function policy value, and if the function policy condition is satisfied, transmits either an activation command or a deactivation command corresponding to the function to the ECU, and if the function policy condition is not satisfied, transmits a policy signal to the ECU to maintain a function lock state.

[0013] The control unit generates function state determination data based on the result of verifying the integrity of the function token, whether a function session key is generated, and the result of generating either a function activation signal or a function deactivation signal; generates function state history data by concatenating the function state determination data in chronological order; and the function state history data includes a function activation time, a function deactivation time, a function lock maintenance time, and a corresponding function subscription information identifier. In the event that a change in function subscription information or a retransmission of the function token occurs for the same vehicle, the control unit blocks duplicate function activation and unauthorized reactivation based on the function state history data.

[0014] The above control unit is characterized by generating function token reuse determination data by comparing the reception time information of function token data received in the communication section between the vehicle and the server, the number of repeated receptions of the same function token, and the timestamp information included in the function token, and identifying the corresponding function token as an invalid token if the function token reuse determination data deviates from the normal range, and, when identified as an invalid token, generating a function invalidation signal and simultaneously storing the reason for invalidation and the determination time in the function status history data, thereby preventing a situation in which the same function is repeatedly activated due to network retransmission, communication delay, or function token duplication.

[0015] The control unit generates function reliability evaluation data based on the number of function activations, the number of function invalidations, and the accumulated time of function lock maintenance included in the function status history data, and the function reliability evaluation data is calculated based on whether a function invalidation signal was repeatedly generated for the same function within a certain period and the ratio of the time the function lock state was sustained, and is characterized by controlling to restrict the generation of a function activation signal for the corresponding function if the function reliability evaluation data is determined to be below a reference reliability range.

[0016] The control unit is characterized by being configured to control, for a function for which the generation of a function activation signal is restricted according to the function reliability evaluation data, to shorten the integrity verification cycle of the function token and increase the update cycle of temporary random numbers r_v and r_s for generating a function session key, and to re-allow the generation of the function activation signal only when the integrity of the function token re-verified according to the shortened verification cycle and the increased random number update cycle is continuously determined to be normal.

[0017] The above control unit is characterized by identifying a function activation priority for each ECU based on the function status history data and device load value when a function activation signal is simultaneously transmitted to a plurality of ECUs through the Software-Defined Vehicle-based gateway, and controlling the function activation signal to be transmitted sequentially by separating it in time according to the identified function activation priority, thereby preventing function conflicts or temporary malfunctions between ECUs even in situations of simultaneous activation of multiple functions due to on-demand function subscription.

[0018] The above control unit is characterized by being configured to generate function control judgment data by combining at least two of the function token integrity verification result, function session key generation result, function status history data, function token reuse determination data, and function reliability evaluation data, and to generate a function activation signal only when the function control judgment data satisfies all of a plurality of independent conditions. Effects of the invention

[0019] Function subscription information for determining the activation or deactivation of functions of an electronic control unit within a vehicle is stored in the server's storage, and the integrity of the function token is verified by combining the vehicle's unique identification information, the function subscription information, and the received post-quantum cryptography-based public key data, thereby ensuring that the function token is treated as a verification target dependent on the vehicle and subscription status rather than as simple identification information.

[0020] By applying post-quantum cryptography-based integrity verification using Kyber-based or Dilithium-based parameter verification formulas, the potential for long-term security degradation, which was an issue in existing public-key cryptography, is structurally resolved, and functional subscription security can be maintained even in future quantum computing environments,

[0021] After the integrity verification of the function token is completed, a new function session key is generated by combining a temporary random number generated by the in-vehicle function subscription module with a random number received from the server, and an encrypted control command for the function activation signal is generated using the said function session key and transmitted to the vehicle gateway. Through this, the process of determining function activation and transmitting the actual ECU control command is protected by being separated into session units rather than relying on a single fixed key, thereby effectively reducing the risk associated with the reuse or tampering of the control signal.

[0022] Consequently, by linking function token verification, session key renewal, and encrypted control command transmission throughout the entire process from the vehicle start-up to the transmission of function activation commands, it is possible to provide a mobility-based on-demand function subscription security system that structurally prevents unauthorized function activation, function token reuse, and control signal falsification / tampering issues that were problematic in conventional technology, and substantially improves security reliability in a mobility-based on-demand function subscription environment. Brief explanation of the drawing

[0023] FIG. 1 is a diagram illustrating the schematic configuration of a mobility-based on-demand function subscription security system according to one embodiment of the present invention. FIGS. 2 to 6 are drawings illustrating an example of operation of a mobility-based on-demand function subscription security system according to an embodiment of the present invention. Specific details for implementing the invention

[0024] Embodiments of the present invention will be described in detail below with reference to the accompanying drawings. In the drawings, identical reference numbers or symbols refer to components that perform substantially the same function, and the size of each component in the drawings may be exaggerated for clarity and convenience of explanation. However, the technical concept of the present invention and its core components and operations are not limited only to the components or operations described in the following embodiments. In describing the present invention, if it is determined that a detailed description of known technologies or components related to the present invention may unnecessarily obscure the essence of the present invention, such detailed description will be omitted.

[0025] In embodiments of the present invention, terms including ordinal numbers, such as first, second, etc., are used solely for the purpose of distinguishing one component from another, and singular expressions include plural expressions unless the context clearly indicates otherwise. Furthermore, in embodiments of the present invention, terms such as 'composed of,' 'include,' 'have,' etc., should be understood as not precluding the existence or addition of one or more other features, numbers, steps, actions, components, parts, or combinations thereof. Additionally, in embodiments of the present invention, 'module' or 'part' performs at least one function or operation and may be implemented in hardware or software, or as a combination of hardware and software, or may be integrated into at least one module and implemented as at least one processor. Furthermore, in embodiments of the present invention, 'at least one' among a plurality of elements refers not only to all of the plurality of elements but also to each individual element excluding the remainder or all combinations thereof. Additionally, "configured to" may be used interchangeably with, depending on the context, for example, "suitable for," "having the capacity to," "designed to," "adapted to," "made to," or "capable of." "Configured to" does not necessarily mean that it is "specifically designed to" in hardware. Instead, in some situations, the expression "device configured to" may mean that the device is "capable of" doing so in conjunction with other devices or components.For example, the phrase “a processor configured (or set) to perform A, B, and C” may mean a dedicated processor for performing said operations (e.g., an embedded processor), or a generic-purpose processor (e.g., a CPU or an application processor) capable of performing said operations by executing one or more software programs stored in a memory device.

[0026] Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the drawings. This description is intended to be detailed enough for a person skilled in the art to easily practice the invention, and it should be noted that the technical scope and concept of the present invention are not limited thereby.

[0027] FIG. 1 is a diagram illustrating the schematic configuration of a mobility-based on-demand function subscription security system according to one embodiment of the present invention, and FIG. 2 to 6 are diagrams illustrating an example of the operation of a mobility-based on-demand function subscription security system according to one embodiment of the present invention.

[0028] Referring to FIGS. 1 to 6, a mobility-based on-demand function subscription security system according to one embodiment of the present invention includes a server and a user terminal connected to the server via a wired or wireless network.

[0029] Mobility according to one embodiment of the present invention refers to the entirety of means for performing the movement of people or cargo within a physical space, and can be understood as a concept including a moving body and an operating system thereof that can be implemented in various forms depending on the object of movement, the method of movement, the power source, the control method, or the operating environment. Such mobility may be composed of a single device or may be composed in the form of a complex system combining multiple mechanical, electronic, and communication components.

[0030] The above mobility may be designed to be mobile in at least one of road, rail, air, or maritime environments, and the mode of movement may be implemented using wheels, tracks, propellers, buoyancy devices, or similar means of movement. Additionally, the mobility may be operated in a manned or unmanned manner, and movement may be performed under the direct control of a driver or operator, or movement may be performed automatically or semi-automatically in conjunction with sensors, control logic, or external systems.

[0031] The above-mentioned mobility may be driven using various power sources, such as internal combustion engines, electric drive sources, hydrogen fuel cells, or hybrid methods combining multiple energy sources, and the power sources may be configured differently depending on the size, purpose, and operating conditions of the mobility. Such power sources may be configured to generate propulsion for movement by being mechanically connected to a motor, engine, or drive shaft, and may operate in conjunction with an energy storage device or an external energy supply device.

[0032] In addition, the mobility may include electronic control components for performing various functions while moving or stationary. For example, the mobility may include sensors for detecting driving conditions, electronic control units for controlling internal conditions, and communication means for exchanging information with a user or an external system, and these components operate independently or in an interconnected manner to manage the operational status of the mobility. In this case, the electronic control components may be arranged in a modular structure or controlled collectively by an integrated control unit.

[0033] The above mobility may be utilized for various purposes, such as personal mobility, logistics mobility, industrial mobility devices, or public service vehicles, and the passenger space, cargo space, safety devices, or user interface may be configured differently depending on the field of application. Additionally, the above mobility may be designed to accommodate a single user or multiple users and may further include components that provide information, convenience features, or additional services to the user while in motion.

[0034] As such, the mobility mentioned in this specification is not limited to a specific structure, size, power method, or operating method, but can be interpreted as a concept encompassing all forms of devices and operating systems that perform movement, and is capable of various modifications and extensions depending on technological advancements or changes in the application environment. Accordingly, the description of the mobility is illustrative, and the technical concept of the present invention is not limited by the specific form or method of implementation of such mobility.

[0035] On-demand function subscription security according to one embodiment of the present invention refers to the overall technology for protecting the availability and scope of provision of a plurality of functions provided by a device, system, or service in an on-demand function subscription environment in which some or all of the said functions are selectively provided according to a user's choice, contract status, or operating conditions. The fundamental purpose of such on-demand function subscription security is to ensure that the activation, deactivation, maintenance, or restriction of functions is accurately performed according to defined conditions, and it may include various security elements to prevent unauthorized access, unauthorized use, or falsification or alteration of the function status that may occur during the function provision process.

[0036] The above-mentioned on-demand feature subscription security may include a structure that manages feature usage rights to be limited to specific points in time, specific conditions, or specific targets, based on the relationship between the feature provider and the target using the feature. To this end, information indicating the feature subscription status, feature identification information, user or device identification information, and information related to the feature provision period or frequency may be managed in combination, and such information may be utilized as a criterion for determining whether to provide the feature, either individually or in a combined form.

[0037] In addition, the on-demand function subscription security described above may include a verification procedure to ensure the reliability of control signals or data exchanged during the function provision process. For example, it may include a verification step to determine whether a function activation request was generated through a normal procedure, whether the authorization information required for function provision is valid, or whether the same function request is being repeatedly reused. This verification procedure may be performed as a single step, or multiple steps may be performed sequentially in chronological order.

[0038] The above-mentioned on-demand function subscription security can be implemented in conjunction with data transmission in a communication environment and may include protection means to prevent situations in which function-related information transmitted via a wired or wireless network is altered or forged during transmission. In this case, the protection means may include at least one of various methods such as encryption, authentication, integrity verification, or access control, and different methods may be applied in combination depending on the characteristics of the function provision environment.

[0039] In addition, the above-mentioned on-demand feature subscription security may include a monitoring or history management structure for continuously managing the provision status of the feature. For example, the time when the feature was activated, the time when it was deactivated, the period during which its provision was restricted, or the history of changes in the feature provision conditions may be recorded, and such historical information may be used as a standard for determining whether to provide the feature in the future or for adjusting security policies.

[0040] As such, the on-demand feature subscription security mentioned in this specification is not a concept limited to a specific industry, specific device, or specific implementation method, and can be widely applied to various systems implemented in the form of software, hardware, or a combination thereof. Furthermore, since it can be modified or expanded in various forms depending on changes in the method of providing functions, security policies, or operating environments, the description of the on-demand feature subscription security is merely illustrative, and the scope of the present invention is not limited by this.

[0041] User terminals include, for example, personal computers, server computers, handheld or laptop devices, mobile devices (mobile phones, PDAs, media players, etc.), multiprocessor systems, consumer electronic devices, minicomputers, mainframe computers, distributed computing including any of the aforementioned systems or devices, and edge computing environments in which data is processed at the edge where data is generated rather than at a central server, and the configuration is not limited to only those described.

[0042] The user terminal may include at least one processor and memory. Here, the processor may include, for example, a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor, an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), etc., and may have multiple cores.

[0043] Memory may be volatile memory (e.g., RAM, etc.), non-volatile memory (e.g., ROM, flash memory, etc.), or a combination thereof. Additionally, the user terminal may include additional storage. Storage includes, but is not limited to, magnetic storage, optical storage, etc. Computer-readable instructions for implementing one or more embodiments disclosed herein may be stored in the storage, and other computer-readable instructions for implementing an operating system, an application program, etc. Computer-readable instructions stored in the storage may be loaded into memory to be executed by a processor.

[0044] Additionally, the user terminal may include a user input unit and an output device. The user input unit may include, for example, a keyboard, a mouse, a pen, a voice input device, a touch input device, an infrared camera, a video input device, or any other input device. Additionally, the output device may include, for example, one or more displays, speakers, printers, or any other output devices. Additionally, the computing device may use an input device or an output device provided in another computing device as a user input unit or an output device. Additionally, the computing device may include a communication module that enables the computing device to communicate with another device. Here, the communication module may include a modem, a network interface card (NIC), an integrated network interface, a radio frequency transmitter / receiver, an infrared port, a USB connection, or other interfaces for connecting the computing device to another computing device. The communication module may include a wired connection or a wireless connection.

[0045] Each component of a user terminal may be connected by various interconnections such as buses (e.g., Peripheral Component Interconnect (PCI), USB, firmware (IEEE 1394), optical bus structures, etc.) or may be interconnected by a network. Terms such as “component,” “system,” etc. as used herein refer to computer-related entities that are generally hardware, a combination of hardware and software, software, or running software.

[0046] A user terminal according to one embodiment of the present invention may include a display unit, and the method of implementing the display unit is not limited and may be implemented using various display methods such as liquid crystal, plasma, light-emitting diode, organic light-emitting diode, surface-conduction electron-emitter, carbon nanotube, nanocrystal, etc. In the case of a liquid crystal method, the display unit includes a liquid crystal display panel, a backlight unit that supplies light to the liquid crystal display panel, and a panel driver unit that drives the liquid crystal display panel. Meanwhile, the display unit may be implemented as an OLED panel, which is a self-emissive element, without a backlight unit.

[0047] A server according to one embodiment of the present invention includes: a storage unit for storing function subscription information for determining whether to activate or deactivate the function of an electronic control unit within a vehicle; a control unit for performing operations to verify the integrity of a function token using the vehicle's unique identification information, function subscription information, and received post-quantum cryptography-based public key data; and a communication unit for receiving function token data generated in a communication section between the vehicle and the server.

[0048] A communication unit according to one embodiment of the present invention may communicate with a user terminal or other external electronic device, etc., via wired or wireless communication methods. Accordingly, in addition to a connection unit including a connector or terminal for wired connection, it may be implemented using various other communication methods. For example, it may be configured to perform one or more of Wi-Fi, Bluetooth, Zigbee, infrared communication, Radio Control, Ultra-Wide Band (UWM), Wireless USB, and Near Field Communication (NFC). The communication unit may include communication modules such as Bluetooth Low Energy (BLE), Serial Port Profile (SPP), Wi-Fi Direct, infrared communication, Zigbee, and Near Field Communication (NFC). Furthermore, the communication unit may be implemented in the form of a device, a software module, a circuit, a chip, etc.

[0049] A communication unit according to one embodiment of the present invention may include various communication modules as described above, and may include an IoT communication module having an IoT network for each carrier. An IoT communication module may refer to any IoT communication network in which a plurality of objects having separate communication units are connected through a network to enable services based on various platforms. By using such an IoT communication module, a smoother communication network can be provided within a set area.

[0050] A storage unit according to one embodiment of the present invention may receive information from a user terminal or from an external search platform through a communication unit and store it, and may receive text information and image information included in a plurality of web pages received by a control unit and store them. The storage unit may store various data according to the processing and control of the control unit described below. The storage unit may be accessed by the control unit to perform reading, recording, modification, deletion, and updating of data. The storage unit may include non-volatile memory such as flash memory, a hard disk drive, or a solid-state drive (SSD) so as to preserve data regardless of whether system power is provided to the server. Additionally, the storage unit may include volatile memory such as a buffer or RAM for temporarily loading data processed by the control unit.

[0051] A control unit according to one embodiment of the present invention can perform control for the operation of various components of a server. The control unit may include a control program (or instruction) that enables such control operation, an inactive memory in which the control program is installed, a volatile memory in which at least a portion of the installed control program is loaded, and at least one processor or CPU (Central Processing Unit) that executes the loaded control program. In addition, such a control program may be stored in an external electronic device other than the server.

[0052] The control program may include program(s) implemented in at least one form among BIOS, device driver, operating system, firmware, platform, and application. In one embodiment, the application may be pre-installed or stored on the server at the time of manufacturing the server, or may be installed on the server based on data received from an external source when used later. The data of the application may be downloaded to the server from an external server, such as an application market, for example, a platform according to the present invention, but is not limited thereto. Meanwhile, the control unit may be implemented in the form of a device, S / W module, circuit, chip, etc., or a combination thereof.

[0053] A storage unit according to one embodiment of the present invention stores function subscription information for determining whether to enable or disable a function of an electronic control unit within a vehicle. Function subscription information refers to a set of information for determining whether a function among the functions available for a specific vehicle is in an enabled state or a restricted state, and is composed of data that includes function identification, application conditions, and application scope, rather than a simple flag value.

[0054] The function subscription information stored in the above storage unit may include, for example, a function identifier defined based on a list of functions for each electronic control unit installed in the vehicle, and a status value indicating whether the corresponding function is in an active state corresponding to each function identifier. In this case, the function identifier may be implemented as an integer code, a string code, or a combination thereof, and is managed to ensure that there are no duplicates within the same vehicle. The status value may be implemented as a binary value, but in actual implementation, it may be stored as a multi-bit or enumerated value to distinguish multiple states such as active, inactive, paused, and awaiting expiration.

[0055] In addition, the aforementioned function subscription information may also store condition information necessary for determining whether a function is enabled or disabled. This condition information may consist of quantifiable condition values, such as the time range during which the function is permitted, the number of times the function can be used, or the duration for which the provision of the function is maintained. For example, the function usage period may be stored as a timestamp pair containing a start time and an end time, and the number of times the function can be used may be stored as an integer value representing the remaining number of uses. These condition values ​​are designed to be updated in the vehicle or server, and the storage unit is managed to reflect the condition values ​​in their latest state.

[0056] The above storage unit may be configured to store function subscription information in conjunction with the vehicle's unique identification information. To this end, a structure may be applied to the storage unit in which vehicle identification information is used as a key value and multiple function subscription information is mapped to the corresponding key value. For example, if the vehicle identification information is defined as a unique code in the form of a string, the storage unit stores a record structure containing a list of function identifiers and the status and condition values ​​of each function based on the vehicle identification information. Through such a mapping structure, different subscription states can be managed for each vehicle, even for the same function.

[0057] The above-mentioned function subscription information can be defined based on subscription change history data collected in an actual vehicle operation environment. For example, log data such as the time of a function activation request, the time of a function deactivation request, or the time when a subscription change request is approved or rejected can be collected over a certain period, and the range of state and condition values ​​of the function subscription information can be set based on function state transition patterns that appear repeatedly in the log data. This log data can be utilized to calculate the number of transitions, retention time, and change frequency for each function while sorted in chronological order, and the expression range of function state values ​​or the storage unit of condition values ​​is determined based on the results.

[0058] The above storage unit may be implemented in at least one form among non-volatile memory, a database, or a file system, and is configured so that function subscription information can be maintained even after the vehicle power is cut off. In addition, if a change in function subscription information occurs, the information before and after the change may be stored using an overwrite method or a history accumulation method, and the possibility of restoring previous information is determined according to the implementation environment. This storage method is intended to ensure that information necessary for determining function activation or deactivation is not omitted, and can be easily implemented by a person skilled in the art by designing a memory structure or a database schema.

[0059] As such, the storage unit can be understood not merely as a means of storing function subscription information for determining the activation or deactivation of functions of the electronic control unit within the vehicle, but as a configuration that stores function subscription information in a concrete data structure that can be directly used for function identification, status determination, and condition verification; furthermore, this storage method is not limited to a specific storage medium or specific data format and can be modified in various implementation ways.

[0060] A communication unit according to one embodiment of the present invention can receive function token data generated in a communication section between a vehicle and a server. A communication section between a vehicle and a server refers to a path through which data is exchanged via a wired or wireless network between a communication device mounted on a vehicle and a server located remotely, and may include a mobile communication network, a short-range wireless communication network, or a similar data transmission environment.

[0061] The communication unit is configured to identify and receive function token data as a recipient from among the data streams transmitted through the communication section. To this end, the communication unit can determine whether the data is function token data based on identification information included in the header area or payload area of ​​the received data packet. For example, function token data may be configured to include a predefined message type code, a fixed data length range, or an identification field placed at a specific location, and the communication unit selects only function token data as an input target by sequentially checking these identification fields.

[0062] The function token data received by the communication unit may be received in the form of a byte array, a string, or a structured data block. The communication unit may load the received raw data directly into a buffer or recombine it by transmission unit to align it into complete function token data units. For example, if the function token data is divided into multiple packets for transmission, the communication unit rearranges the packets based on the sequence information included in each packet, checks for omissions, and combines them into a single function token data. This recombination process can be implemented by comparing packet numbers or accumulating received lengths, and can be easily implemented by a person skilled in the art through network programming.

[0063] In addition, the communication unit can check for transmission errors during the input process of function token data. To this end, the communication unit can verify data corruption by comparing whether an error detection value included in the received data—such as a checksum or hash value—matches a value recalculated from the body of the received data. In this case, the checksum calculation can be performed using byte-unit aggregation or simple hash operations, and since the calculation process is repeated in proportion to the data length, it does not require special mathematical skills for implementation. This method can be applied based on an error detection rate verified through repeated data transmission and reception tests in actual communication environments.

[0064] The communication unit described above may include an input buffer for temporarily storing received function token data, and the buffer retains the data until it is determined whether the function token data has been received in a complete form. The size of the input buffer may be set based on the average function token data size measured in an actual vehicle-server communication environment and the amount of packets accumulated under a maximum transmission delay situation. For example, by repeatedly measuring the average size of function token data and the maximum number of split packets in an actual vehicle communication test environment and calculating the buffer size based on the results, the system can be designed to prevent loss due to data overload.

[0065] As such, the communication unit is not limited to merely receiving function token data generated in the vehicle-server communication section; it can be configured to identify the data as function tokens, reassemble the fragmented data, and input it into the system after verifying for errors. The configuration and operation of this communication unit are not limited to a specific communication method or protocol, and can be implemented according to the same principles in various communication environments as long as the function token data is transmitted over a network.

[0066] A control unit according to one embodiment of the present invention performs operations to verify the integrity of a function token using the vehicle's unique identification information, function subscription information, and received post-quantum cryptography-based public key data. Verification of the integrity of a function token refers to a procedure for determining whether the function token has not been altered or forged during the transmission, storage, and retransmission processes after issuance, and includes operations to verify the consistency of the data content, rather than a simple format check.

[0067] The unique identification information of the above vehicle is an identification value used to distinguish a specific vehicle from other vehicles, and can be defined as a fixed value assigned during the vehicle manufacturing stage or the initial registration stage. This unique identification information may be implemented, for example, as a vehicle identification code in the form of a string, a number-based serial value, or a combination thereof, and the control unit retrieves the corresponding value from internal memory or an external storage area and uses it as an input value for calculations. The unique identification information is used as reference data to determine whether a function token was issued in dependency of a specific vehicle.

[0068] The above-mentioned function subscription information is information indicating the range and status of functions allowed for the vehicle, and can be defined as a data structure including a function identifier and the active or inactive status of the corresponding function. The control unit can verify whether the function token matches the current subscription status by comparing the function identifier included in the function token with the function identifier stored in the function subscription information. This comparison can be performed by checking for a match between string or integer values, and can be easily implemented by a person skilled in the art using conditional statements.

[0069] The received post-quantum cryptography-based public key data mentioned above is a public key value used for signature verification of a function token or key derivation operations, and may be data transmitted in advance from the server or received together with the function token. This public key data may be received in the form of a fixed-length byte array or a text-encoded string, and the control unit uses the data as an input for operations together with the signature value or verification value included in the function token. The length and format of the public key data may be defined according to the specifications of the post-quantum cryptography algorithm, and the control unit verifies only whether the format is maintained upon reception.

[0070] To verify the integrity of the function token, the control unit first extracts a data area to be verified from the function token. This data area can be defined as the portion of the entire function token used during signature generation, and may, for example, be a continuous data block containing the vehicle's unique identification information, function identifier, and issuance time information. The control unit generates verification input data by combining this data block in the same order. This combining process can be performed using string concatenation or byte array merging methods.

[0071] Subsequently, the control unit uses the combined verification input data and the post-quantum cryptography-based public key data to determine whether the signature value included in the function token was generated successfully. At this time, the control unit inputs the verification input data into a verification function using the public key and compares whether the resulting verification result matches the signature value included in the function token. If the comparison results match, it is determined that the function token has not been altered since issuance; if they do not match, it is determined that some data in the function token has been altered or forged. This comparison operation can be implemented using a byte-level comparison or a hash result comparison method.

[0072] The combination method and verification order of the input data used in the above integrity verification operation can be repeatedly verified through actual function token issuance and verification experiments. For example, by generating a normal function token and an arbitrarily modified function token for the same vehicle and performing the above operation on each, it can be verified whether the normal token and the abnormal token are clearly distinguishable. Based on the results of these repeated tests, the configuration and combination order of the data area subject to verification can be determined, and the operation procedure of the control unit is set according to the results.

[0073] In this way, the control unit determines the integrity of the function token by performing operations that sequentially combine and compare the vehicle's unique identification information, function subscription information, and received post-quantum cryptography-based public key data, rather than using them independently. This computational process is not limited to a specific algorithm implementation method and can be implemented in various ways as long as the definition and combination order of the input data are maintained.

[0074] A control unit according to an embodiment of the present invention receives function token data through the communication unit at the time when the vehicle is started, verifies the integrity of the function token by combining the vehicle identification information and function subscription information stored in the storage unit with the electronic signature and key derivative value included in the function token and substituting them into a post-quantum cryptography-based verification formula, and the temporal order and data processing flow are clearly defined so that each step can be implemented in an actual vehicle operating environment. Here, the time when the vehicle is started refers to the time when the vehicle's power supply is activated and the main electronic control unit is initialized, and at that time, the control unit transitions to a state where it can receive data transmitted from an external server through the communication unit.

[0075] The function token data received through the communication unit described above can be defined as data automatically requested upon vehicle ignition or transmitted from a server in conjunction with a ignition signal. The control unit receives data identified as function token data among the data input from the communication unit and transmits it to an internal processing area; at this time, the received function token data is temporarily stored in the form of raw data. During the reception process, the data length, data format, and basic error status are verified, and this verification can be performed by repeatedly checking the number of packet receptions and whether any packets are missing.

[0076] The vehicle identification information stored in the storage unit is a value used to uniquely identify the corresponding vehicle, and the control unit retrieves this vehicle identification information from the storage unit before performing a function token integrity verification operation. This vehicle identification information is used as reference data to be compared with or combined with vehicle-related information included in the function token. Additionally, the function subscription information stored in the storage unit is information indicating the range of functions allowed for the corresponding vehicle, and is utilized as comparison data to determine whether the function-related information included in the function token matches the current subscription status.

[0077] The electronic signature included in the above function token is verification data generated at the time of function token issuance, and is a value used to confirm that the contents of the function token have not been altered. The control unit separates and extracts the electronic signature area from the function token and reconstructs the data to be verified in the same order as the data area used when generating the signature. At this time, the data to be verified may be defined as a data block combining vehicle identification information, function identification information, and information corresponding to the time of function token issuance.

[0078] The above key derivative value is a value derived from a public key or related parameters during the function token issuance process and is used together in the digital signature verification process. The control unit extracts the key derivative value included in the function token and uses it as an input value for the verification operation together with the received quantum cryptography-based public key data. This combination process can be performed by concatenating data while fixing the order, and can be implemented using string concatenation or byte array merging methods.

[0079] Subsequently, the control unit inputs verification data, which combines the function identification information corresponding to the vehicle identification information and function subscription information, the digital signature, and the key derivative value, into a post-quantum cryptography-based verification formula. Here, the post-quantum cryptography-based verification formula is defined as an operation that produces a signature verification result using the public key and the verification input data, and the control unit compares whether the output of the operation matches the digital signature contained in the function token. If the comparison result matches, it is determined that the contents of the function token have not been altered since issuance; if they do not match, it is determined that the integrity of the function token has been compromised.

[0080] The above integrity verification procedure can be verified through tests performed repeatedly in an actual vehicle starting environment. For example, the verification procedure is performed by receiving a normal function token and a function token with some data modified for the same vehicle, respectively. By confirming whether the normal token consistently passes the integrity verification while the modified token fails, the validity of the input data combination order and the method of applying the verification formula can be verified. Based on the results of these repeated tests, the configuration and combination method of the data subject to verification are determined, and the integrity verification operation procedure of the control unit is established.

[0081] In this way, the control unit is configured to receive function token data at the time of vehicle startup and sequentially perform a series of operations in which the vehicle identification information and function subscription information stored in the storage unit are combined with the digital signature and key derivative value included in the function token and substituted into a post-quantum cryptography-based verification formula, thereby verifying the integrity of the function token in a manner that is practically implementable.

[0082] The post-quantum cryptography-based verification formula according to one embodiment of the present invention is configured to use at least one of a Kyber-based parameter verification formula or a Dilithium-based parameter verification formula. A post-quantum cryptography-based verification formula refers to an operation formula that utilizes parameters generated using a public-key cryptographic algorithm based on a lattice problem for verification, rather than a cryptographic method based on existing integer decomposition or discrete logarithm problems.

[0083] The above Kyber-based parameter verification formula can be understood as a structure that utilizes parameters used in public-key cryptography and key encapsulation mechanisms for verification. The control unit uses public-key parameters generated according to the Kyber method and key derivative values ​​contained in function tokens as inputs to determine whether the corresponding key derivative values ​​were generated through a valid encapsulation procedure. To this end, the control unit extracts the key derivative values ​​contained in the function tokens in the form of byte arrays and substitutes them, along with the public-key parameters, into a decryption or verification operation to check whether the verification value produced as a result of the operation satisfies a predefined format or length. Since this verification process can be performed based on parameter sizes and data structures defined according to the publicly available Kyber specifications, a person skilled in the art can implement it by referring to the relevant specification documents.

[0084] In addition, the above Dilithium-based parameter verification formula may be structured to determine whether the digital signature of a function token is valid by utilizing parameters used in a lattice-based signature algorithm for digital signature verification. The control unit extracts the digital signature value contained in the function token, reconstructs the data blocks corresponding to the message used during signature generation in the same order, and then applies them to a verification operation using Dilithium public key parameters. At this time, the result of the verification operation is classified into cases where the signature was successfully generated and cases where it was not, and the control unit determines the integrity of the function token based on the result.

[0085] The aforementioned Kyber-based and Dilithium-based parameter validation formulas may be applied selectively during the same function token validation process, or one of the two may be applied fixedly depending on the implementation environment. For example, if the data structure included in the function token contains an electronic signature field, the Dilithium-based validation formula may be applied, and if it contains a field associated with key exchange or session key derivation, the Kyber-based validation formula may be applied. These selection criteria can be defined in advance based on the function token data format.

[0086] The validity of applying the above verification formula can be verified through actual data-based testing. For example, a function token generated through a normal issuance procedure and an abnormal token in which some bytes of the function token have been arbitrarily modified are prepared, and a Kyber-based or Dilithium-based verification formula is applied to compare the verification results. By confirming whether the normal token consistently passes verification even in repeated tests while the abnormal token fails verification, it can be verified that the verification formula is suitable for determining the integrity of the function token. Such tests can be performed repeatedly on different combinations of vehicle identification information and function subscription information, and the method of applying the verification formula is determined based on the results.

[0087] As such, the above-mentioned post-quantum cryptography-based verification formula is constructed using at least one of a Kyber-based parameter verification formula or a Dilithium-based parameter verification formula, and each verification formula is implemented to determine the integrity of a function token by computationally verifying the relationship between the digital signature or key derivative value included in the function token and the public key parameters. This configuration is not limited to a specific implementation library or execution environment and can be implemented in various ways according to the standard specifications of lattice-based public key cryptographic algorithms.

[0088] A control unit according to one embodiment of the present invention generates a function activation signal to activate a function corresponding to function subscription information when the verification result according to the post-quantum cryptography-based verification formula is normal, and generates a function invalidation signal to maintain the corresponding function in a locked state when the verification result according to the post-quantum cryptography-based verification formula is abnormal.

[0089] A valid verification result refers to the case where, when the digital signature and key derivative of the function token are substituted into a post-quantum cryptography-based verification formula, the output of the formula matches a predefined valid value; an abnormal result refers to the case where the output does not match or an error occurs during the calculation process.

[0090] The above-mentioned function activation signal is a control signal for converting a function corresponding to the function subscription information into an actually usable state. At the time when the verification result is determined to be normal, the control unit identifies the corresponding function based on the function identifier included in the function subscription information. Subsequently, the control unit generates a function activation signal by combining the corresponding function identifier with a status value indicating the activation state. This signal may be defined, for example, as a data structure containing a function identifier code and an activation flag, and a person skilled in the art may implement it in the form of a message structure or a control command frame.

[0091] The generation time of the above function activation signal can be set immediately after the operation result of the post-quantum cryptography-based verification formula is derived, and the control unit may generate a signal after checking the history of the function activation signal generated immediately prior to prevent duplicate activation signals from being generated for the same function. This verification can be performed by comparing the function identifier with the last activation time, which can be implemented through a simple comparison operation.

[0092] Meanwhile, if the verification result based on the above-mentioned post-quantum cryptography-based verification formula is determined to be abnormal, the control unit generates a function nullification signal. The function nullification signal is a control signal intended to prevent the corresponding function from being activated, and may include a state value indicating a nullified state along with a function identifier. By generating the function nullification signal, the control unit can control the function to immediately switch it to an unusable state even if it was previously activated, or to block it even if an activation request is received.

[0093] The lock state maintained according to the above-mentioned function invalidation signal refers to a restricted state in which a new function activation signal is not generated even if an additional activation attempt occurs for the corresponding function. To maintain this lock state, the control unit may update the status value of the corresponding function included in the function subscription information to an inactive or locked state, and this status value is reflected in the storage unit and used for subsequent function control decisions.

[0094] The validity of generating the above-mentioned function activation signal and function deactivation signal can be verified through actual data-based testing. For example, a normal function token and an abnormal function token with some data modified can be received, and a verification formula based on post-quantum cryptography can be applied to repeatedly verify whether a function activation signal is generated only for the normal token and a function deactivation signal is generated for the abnormal token. Such testing can be performed multiple times for the same function, and based on the results, it can be confirmed that the signal generation conditions are stably maintained.

[0095] In this way, the control unit clearly distinguishes and generates a function activation signal or a function nullification signal based on the verification result of a post-quantum cryptography-based verification formula, and maintains the corresponding function in a locked state for abnormal verification results, thereby configuring the function control according to the function subscription information to be performed in a manner that is actually implementable and predictable.

[0096] A control unit according to one embodiment of the present invention further includes the step of, after the integrity verification of the function token is completed, generating a new function session key according to the post-quantum-based session key update function SK′ = H(r_v ∥ r_s ∥ vehicle identification information ∥ function subscription information) using a temporary random number r_v generated in a function subscription module within the vehicle and a random number r_s received from a server, and generating an encrypted control command for a function activation signal using the function session key and transmitting it to a vehicle gateway.

[0097] A control unit according to an embodiment of the present invention is configured to perform subsequent procedures only after the integrity verification of the function token is completed. At this time, a new function session key is generated using a temporary random number r_v generated by a function subscription module within the vehicle and a random number r_s received from a server. Here, the completion of the integrity verification of the function token means that the function token has not been tampered with according to the previously performed post-quantum cryptography-based verification formula and has been determined to be a valid token corresponding to the vehicle and function subscription information. Since the control unit enters the session key generation step based on this determination result as a condition, it structurally blocks a situation in which a control command is generated based on a function token whose integrity has not been verified.

[0098] The above-mentioned temporary random number r_v is a value generated by the in-vehicle function subscription module and is newly generated whenever the vehicle starts or the function activation procedure is initiated. This temporary random number can be generated using a pseudo-random number generator or a hardware random number generator, and can be implemented in the form of a bit sequence or byte array of a fixed length. For example, r_v can be generated using an internal timer value, a counter value, or an entropy source as input so that it becomes a new value independent of the previous start time within the vehicle. This method allows for the verification that different r_vs are generated even within the same vehicle by checking for random number duplication through repeated start tests in an actual vehicle environment.

[0099] The random number r_s received from the server is a value generated on the server side and transmitted to the vehicle, and is combined with r_v generated on the vehicle side to serve as a factor that enhances the non-determinism of the session key. The control unit may receive r_s, received through the communication unit, as a data item separate from the function token, or extract it from a part of the function token data. This random number is also defined as data of a fixed length and is newly generated by the server periodically or upon request.

[0100] The control unit combines the vehicle identification information and function subscription information with the above r_v and r_s and inputs them into a post-quantum-based session key update function. Here, the post-quantum-based session key update function SK′ = H(r_v ∥ r_s ∥ vehicle identification information ∥ function subscription information) can be implemented by concatenating the input data in a specific order and then applying it to a hash function H to generate an output value. The order of data concatenation is fixed as r_v, r_s, vehicle identification information, and function subscription information, and each data is serialized into a byte array or string form before being concatenated. The hash function H is a function that generates a fixed-length output value regardless of the input length, and can be implemented by a person skilled in the art using a standard hash algorithm.

[0101] The function session key generated in this manner is used as a temporary key valid only during the corresponding function activation procedure. The control unit stores the function session key in internal memory and performs encryption using the key before transmitting the function activation signal as an actual control command. The encryption target may consist of the function identifier, activation status value, or control command code included in the function activation signal; the control unit organizes this into a single data block and then performs symmetric key encryption using the function session key.

[0102] The encrypted control command is generated in a data format distinct from the plaintext function activation signal, and the control unit transmits this encrypted control command to the vehicle gateway. The vehicle gateway can decrypt the encrypted control command using the same function session key and convert it into a control signal that can be transmitted to the actual ECU. During this process, if the function session key does not match or the data is tampered with, decryption cannot be performed successfully, thereby preventing a situation where an incorrect control command is transmitted to the ECU.

[0103] The validity of the above session key generation and encryption procedures can be repeatedly verified in an actual communication environment between a vehicle and a server. For example, session keys can be generated using different combinations of r_v and r_s for the same function, and by verifying whether a control command encrypted with the generated session key is successfully decrypted, it can be confirmed whether the session key update is performed correctly. Furthermore, by checking whether the decryption result changes if either r_v or r_s is modified, it can be verified that the session key is substantially dependent on the input data.

[0104] Accordingly, the control unit is configured to ensure that function activation control is safely performed based on a one-time key by additionally including the step of generating a new function session key according to a post-quantum-based session key update function using temporary random numbers r_v and r_s only after the function token integrity verification is completed, and generating an encrypted control command for a function activation signal using the said function session key and transmitting it to the vehicle gateway.

[0105] A control unit according to one embodiment of the present invention transmits at least one of a function activation signal or a function deactivation signal generated in a state protected by the function session key to a Software-Defined Vehicle-based gateway, and determines a function policy condition using current function status data received from the gateway. A state protected by the function session key means that the function activation signal or the function deactivation signal is not in a plaintext state, but is generated in a state that has been encrypted using the previously generated function session key.

[0106] The above function activation signal or function deactivation signal is generated by the control unit and then converted into an encrypted control message form through encryption operations using a function session key. This encrypted control message may include a function identifier, a code indicating the control type, and a status value, and the data is composed of a single continuous data block and then input into an encryption function that takes the function session key as an input value. In this process, even if it is the same function, the function session key is updated every time, so the encryption result is generated differently for each function activation request.

[0107] The control unit transmits the encrypted control message generated in this way to a Software-Defined Vehicle-based gateway. The gateway serves as an intermediate control point interconnected with multiple electronic control units within the vehicle network and has a structure capable of decrypting the encrypted control message using a functional session key after receiving it. When transmitting the control message to the gateway, the control unit can determine whether the control message has been successfully delivered by verifying whether the transmission was successful or whether a response was received.

[0108] The current function status data received from the above gateway is data reflecting the processing result according to the control message, and includes information indicating whether the corresponding function is actually active, inactive, or maintained in a locked state. This function status data may be received in the form of structured data including a function identifier and a status value, and the control unit receives this data through the communication unit and stores it in an internal processing area.

[0109] The control unit determines the function policy conditions using the current function state data. Here, function policy conditions refer to criteria for determining whether a specific function is allowed to remain in an active or inactive state from its current state, and the control unit performs this determination by comparing the state value included in the function state data with a predefined policy criterion. For example, if the function state data indicates an active state, the control unit re-verifies whether the corresponding function is in a state allowed by the function subscription information, and determines to maintain that state only if they match.

[0110] This process of determining function policy conditions can be verified through repetitive function control tests in an actual vehicle environment. For example, by alternately transmitting function activation and deactivation signals for the same function and receiving the corresponding function status data, it is possible to verify whether the control unit's judgment results are consistently maintained. In this process, by confirming that decoding is performed normally at the gateway even when the function session key changes and that the function status data is accurately reflected based on the result, it can be verified that the control unit's policy judgment logic operates stably based on actual data.

[0111] In this way, the control unit transmits a function activation signal or a function deactivation signal, generated while protected by a function session key, to a Software-Defined Vehicle-based gateway, and determines function policy conditions using the current function status data received from the gateway, thereby configuring function control to be performed based on the correspondence between the encrypted control signal and the actual function status.

[0112] According to one embodiment of the present invention, the functional status data is configured to include whether the function is active, a device load value, and a functional policy value.

[0113] Functional status data refers to current status information indicating the state in which a specific function exists within the vehicle after a control command for that function has been transmitted through a gateway, and it can be understood as a data set combining multiple status indicators rather than a single value.

[0114] The above-mentioned function activation status is information indicating whether the corresponding function is currently available for use, and can be expressed as a binary value or a multiple state value. For example, the function activation status can be classified into an active state, an inactive state, or a locked state, and these state values ​​are set based on response signals received by the gateway from each electronic control unit. After a function activation signal or a function deactivation signal is transmitted, the gateway receives a response value indicating whether the function is actually operating from the electronic control unit performing the corresponding function, organizes this into a function activation status, and transmits it to the control unit.

[0115] The above device load value is information indicating the degree of load applied to relevant devices within the vehicle when a function is activated, and can be defined as a numerical value representing the level of additional resources consumed due to the activation of the function. For example, the device load value can be calculated based on the processing share, communication share, or operation frequency associated with the execution of the function, and this value is calculated by accumulating device operation information collected by the gateway over a certain period of time. Specifically, the gateway can calculate the increase by comparing the number of device operations or processing requests before and after function activation, and convert this into a device load value. This conversion method can be established based on data repeatedly measured through actual vehicle driving and function activation tests.

[0116] The above function policy value is information indicating the status of the control policy applied to the corresponding function, and serves as a criterion value for determining whether the decision to enable or disable the function is permitted under the current policy. The function policy value can be expressed as a status value, such as normal allowance, restricted allowance, or blocking, and is set by reflecting the relationship between the policy conditions defined in the function subscription information and the current function status data. The gateway may transmit to the control unit the result of processing the function activation request, along with the result of determining whether the corresponding function satisfies the policy conditions, by including the result as the function policy value.

[0117] The aforementioned function activation status, device load value, and function policy value are collected independently, but are combined and transmitted as a single structured data form in the function status data. For example, the function status data can be defined as a data structure that includes a function identifier along with a status field indicating function activation status, a numeric field indicating the device load value, and a policy field indicating the function policy value. This data structure can be configured based on a data format verified through iterative function control experiments in an actual vehicle network environment.

[0118] The calculation method for the aforementioned device load and function policy values ​​can be verified during a test process that repeatedly switches between the actual function activation and deactivation states. For example, by collecting device operation frequency and policy judgment results while activating and deactivating the same function multiple times, and confirming whether the results exhibit a consistent pattern with the function activation status, it is possible to verify that each value appropriately reflects the function state. Through such testing, it is confirmed that each component included in the function state data is derived based on actual data.

[0119] As such, the above-mentioned function status data is configured to include whether the function is active, the device load value, and the function policy value, and each component is calculated based on actual operation information collected from devices and gateways within the vehicle and transmitted to the control unit, thereby being implemented so that it can be directly utilized for determining subsequent function policy conditions.

[0120] A control unit according to one embodiment of the present invention is configured to transmit either an activation command or a deactivation command corresponding to the function to the ECU when the function policy condition is satisfied, and to transmit a policy signal to the ECU to maintain a function lock state when the function policy condition is not satisfied. Here, an ECU refers to an electronic control unit that performs the actual operation of a specific function and is controlled to activate or deactivate the function or maintain the current state according to a command signal transmitted from the control unit.

[0121] The case where the above-mentioned function policy condition is satisfied refers to the situation where, as a result of the control unit’s judgment based on the function status data, it is confirmed that the transition of the relevant function to an active or deactivated state is policy-allowed. This judgment is performed based on function status data that includes the function activation status, device load value, and function policy value. For example, the function policy condition may be determined to be satisfied if the function policy value indicates an allowable state and the device load value does not exceed the allowable range due to the execution of the relevant function. This allowable range can be set based on the results of repeatedly measuring the function activation and device operation status during actual vehicle operation, and the standard is determined by confirming a load level at which no ECU response delay or error occurs when a specific function is activated.

[0122] When it is determined that the function policy conditions are satisfied, the control unit determines the command type corresponding to the function. That is, if the function is currently inactive and activation is permitted, it generates an activation command; if the function is currently active and deactivation is required, it generates a deactivation command. The activation or deactivation command may consist of control command data including a function identifier and a command type, and the control unit packetizes this data into a format interpretable by the ECU and transmits it. This process is designed not merely as a simple state transition, but to include clear command codes so that the ECU can initiate or interrupt the actual function execution logic.

[0123] The above command transmission is performed via an in-vehicle communication network, and the control unit can verify whether the command has been successfully transmitted by receiving a response from the ECU regarding whether the command has been received or whether processing has been completed. This verification procedure can confirm that the command transmission structure operates stably by repeatedly transmitting the same command in an actual vehicle test environment and collecting ECU response patterns.

[0124] Conversely, if the above-mentioned function policy conditions are not satisfied, the control unit does not transmit an activation or deactivation command to the ECU, but instead sends a policy signal to the ECU to maintain the function lock state. Here, the function lock state refers to a state in which the corresponding function maintains its current state while no new activation or deactivation transition is permitted. The policy signal may include a function identifier and a code value indicating the lock state, and upon receiving this policy signal, the ECU operates to ignore or suspend additional control requests for the corresponding function.

[0125] The lock-maintaining operation based on the above policy signal is intended to prevent the function state from being arbitrarily changed even when actual function activation requests occur repeatedly. The control unit records whether policy signals are continuously transmitted for the same function and verifies whether the same lock state is maintained for a certain period of time. This verification can be performed by verifying, through repetitive function request testing, whether the ECU function state is stably maintained even after the policy signal is transmitted.

[0126] In this way, the control unit is configured to perform function control stepwise based on predefined policy conditions and the actual vehicle state by transmitting an activation or deactivation command to the ECU depending on whether the function policy conditions are satisfied, or by transmitting a policy signal to the ECU to maintain the function lock state. This control method is not limited to a specific function or ECU and can be applied to various function control scenarios using the same principle.

[0127] A control unit according to an embodiment of the present invention generates function state determination data based on the result of verifying the integrity of the function token, whether a function session key is generated, and the result of generating either a function activation signal or a function deactivation signal, and generates function state history data by concatenating the function state determination data in chronological order, wherein the function state history data includes a function activation time, a function deactivation time, a function lock maintenance time, and a corresponding function subscription information identifier, and in the event that a change in function subscription information or a retransmission of the function token occurs for the same vehicle, duplicate function activation and unauthorized reactivation are blocked based on the function state history data.

[0128] A control unit according to an embodiment of the present invention is configured to generate function state determination data based on the integrity verification result of the function token, whether a function session key is generated, and the generation result of either a function activation signal or a function deactivation signal. Here, the integrity verification result of the function token refers to the determination result regarding whether the function token has been tampered with or forged, and the control unit defines and records a distinguishable state value for cases where the verification is determined to be normal and cases where it is determined to be abnormal. The generation status of the function session key is information indicating whether the session key generation procedure was actually performed after the integrity verification is completed; the control unit sets a state value by distinguishing between cases where the session key generation function is executed normally and a key value is generated, and cases where it is not generated. In addition, the generation result of the function activation signal or the function deactivation signal is defined as a result value indicating whether the control unit generated a control signal for activation or deactivation for the corresponding function, and this can also be expressed as a clearly distinguishable code value or state value.

[0129] The control unit combines the three result values ​​mentioned above into a single data structure to generate functional state determination data. This functional state determination data is not a single judgment result, but a data set that includes results derived from each key step of the functional control procedure; for example, it may be configured to include an integrity verification result field, a session key generation status field, and a control signal generation result field. By recording the results of each step while repeatedly performing the functional activation and deactivation procedures in an actual vehicle environment, this data structure can be verified to ensure that results for each step are generated without omission.

[0130] The control unit generates functional state history data by connecting the generated functional state determination data in chronological order. Here, chronological order refers to the sequence in which functional state determination data occurs based on the actual time point when the functional control procedure was performed. The control unit ensures that the sequential relationship between the data is clearly maintained by storing time information indicating the time of generation together with each functional state determination data. The functional state history data may not be a single data point, but rather implemented in a form in which multiple functional state determination data accumulated over time for the same vehicle are continuously connected.

[0131] The above function status history data is configured to include the function activation time, function deactivation time, function lock maintenance time, and the corresponding function subscription information identifier. The function activation time refers to the point in time when a function activation signal is generated and the corresponding function is switched to an active state, while the function deactivation time refers to the point in time when the function is switched to an inactive state by a function invalidation signal. The function lock maintenance time indicates the point in time when a policy signal is transmitted to maintain the function lock state because the function policy conditions are not satisfied; this is recorded as information to distinguish whether a transition to activation or deactivation has occurred. The corresponding function subscription information identifier is an identification value indicating which function subscription information was used as the basis for function control at that time, and is used as reference information to track whether the function subscription has changed.

[0132] The control unit is configured to block duplicate function activation and unauthorized reactivation based on the function status history data when a change in function subscription information or a retransmission of a function token occurs for the same vehicle. Specifically, the control unit compares the function identifier corresponding to the newly received function token or the changed function subscription information with the previous function activation time and function subscription information identifier stored in the function status history data. As a result of the comparison, if the same function is already maintained in an active state or a locked state is recorded, it can be determined not to initiate a new activation procedure. In addition, even when a function token is retransmitted, the situation in which the same function is repeatedly activated can be prevented by checking whether a record of function activation corresponding to the token already exists in the function status history data.

[0133] This duplicate blocking behavior can be verified through tests in actual vehicle environments, such as repeatedly transmitting function tokens or modifying and restoring function subscription information. For example, when function tokens are transmitted continuously for the same function, the normal operation of the history-based blocking logic can be confirmed by verifying that no additional activation commands occur after the initial activation and only the function status history data is updated. In this way, the control unit is configured to block duplicate function activations and unauthorized reactivations for the same vehicle based on data by progressively generating and utilizing function status determination data and function status history data.

[0134] A control unit according to one embodiment of the present invention generates function token reuse determination data by comparing the reception time information of function token data received in the communication section between the vehicle and the server, the number of times the same function token is repeatedly received, and timestamp information included in the function token.

[0135] Function token data refers to a set of data used to prove the authority to enable or disable a specific function among the data transmitted from the server to the vehicle or from the vehicle to the server during the communication process between the vehicle and the server, and the control unit recognizes the said function token data as a target for processing immediately upon receiving it through the communication unit.

[0136] The above reception time information indicates the time when the function token data was actually received by the vehicle, and the control unit records the function token reception time based on an internal clock or a system timer. This reception time information can be stored in the form of an absolute time value indicating when the function token arrived or a relative time interval from the previous reception time. For example, to verify whether a function token for the same function is received repeatedly within a certain time interval, the control unit may calculate and record the difference between the previous reception time and the current reception time. This time information can be established as a criterion to distinguish between normal retransmission and abnormal repeated transmission through a test of repeatedly transmitting function tokens in an actual vehicle communication environment.

[0137] The number of repeated receptions of the aforementioned identical function token is information indicating how many times an identical function token or a function token containing identification information representing the same function has been received. The control unit determines whether a previously received function token and a currently received function token are identical based on the function identifier or token identification value included in the function token, and if they are determined to be identical, it increases the reception count of the corresponding function token. This number of repeated receptions can be managed simply as an accumulated count, or it can be managed by limiting the number of repetitions within a certain time interval. This management method can be verified through repeated testing to distinguish between patterns of repeated reception that occur normally during actual communication delays or retransmission situations and patterns where the same token is used abnormally.

[0138] The timestamp information included in the above function token indicates the time when the function token was created or issued, and is included and transmitted to the vehicle when the function token is created by the server. The control unit can determine whether the function token is being used within the allowed validity period by extracting this timestamp information from the function token data and comparing it with the current reception time information. For example, if the difference between the timestamp included in the function token and the reception time information exceeds a certain range, it may be determined that the function token is a token issued in the past that is being reused. This criterion for judgment can be set to a time range capable of distinguishing between normal use and reuse through testing that varies the issuance and usage times of the function token in an actual vehicle-server communication environment.

[0139] The control unit generates function token reuse determination data by comparing the reception time information, the number of repeated receptions, and the timestamp information. The function token reuse determination data may consist of data that includes judgment results for each comparison item, rather than a single judgment result. For example, the control unit may determine whether the reception time interval is short, whether the number of repeated receptions exceeds a set number, and whether the difference between the timestamp and the reception time exceeds an allowable range, respectively, and generate function token reuse determination data by combining the results.

[0140] The process of generating such function token reuse determination data can be verified by testing the case where a function token is transmitted normally once in an actual vehicle environment and the case where the same function token is transmitted repeatedly. For example, when the same function token is transmitted repeatedly at regular intervals, it can be confirmed whether it is determined to be reused based on the accumulation of information regarding the number of repeated receptions and the time of reception, and it can be confirmed whether it is not determined to be reused when a new function token is transmitted normally. In this way, the control unit is configured to specifically determine whether a function token is reused by generating function token reuse determination data based on actual data comparison of information regarding the time of reception, the number of repeated receptions, and timestamp information.

[0141] A control unit according to one embodiment of the present invention identifies a function token as an invalid token when the function token reuse determination data deviates from a normal range, and is configured to generate a function invalidation signal when identified as an invalid token and simultaneously store the reason for invalidation and the determination time in the function status history data, thereby preventing a situation in which the same function is repeatedly activated due to network retransmission, communication delay, or function token duplication.

[0142] A control unit according to an embodiment of the present invention is configured to identify a function token as an invalid token when the function token reuse determination data deviates from a normal range. Here, the function token reuse determination data deviating from a normal range means that at least one of the reception time information, the number of repeated receptions of the same function token, or the timestamp information included in the previously generated function token reuse determination data does not satisfy a pre-set permission condition. The control unit checks the determination result for each item and determines that if it exceeds the range considered as normal use, the function token should no longer be used as a valid control basis.

[0143] The process of identifying the above-mentioned function token as invalid does not imply that the contents of the function token itself are modified or deleted, but rather that the control unit classifies the corresponding function token as not being recognized as a control target. For example, the control unit may be configured to prevent it from being referenced in subsequent control procedures by storing an invalid status flag associated with the function token identification value or by registering the function token in a separate list of invalid tokens. This identification method can be verified by confirming that the function activation procedure does not proceed further after the token is classified as invalid through a test involving the repeated transmission of the same function token in an actual vehicle-server communication environment.

[0144] If the control unit identifies a function token as an invalid token, it immediately generates a function invalidation signal. This function invalidation signal is a control signal that prevents the transition to an active state for the corresponding function, and it includes a command code or status value that is clearly distinguishable from the function activation signal described earlier. By transmitting this function invalidation signal to the ECU or gateway, the control unit prevents attempts to activate a function based on an invalid token from leading to actual vehicle function operation.

[0145] Simultaneously, the control unit is configured to store the fact that a token has been identified as invalid in conjunction with the functional status history data. The information stored at this time includes the reason for invalidity and the time of determination. The reason for invalidity is information indicating which item in the functional token reuse determination data has deviated from the normal range, and can be recorded as a distinguishable value, such as, for example, exceeding the number of repeated receptions, exceeding the timestamp validity period, or exceeding the reception time interval. The time of determination is information indicating the actual time at which the control unit determined the corresponding functional token to be invalid, and is stored so as to be temporally linked with other functional control records within the functional status history data.

[0146] The process of storing the reason for invalidation and the time of determination in the aforementioned function status history data is intended to allow reference to past invalidation determination history when a function token is received again for the same vehicle. For example, the control unit checks whether there is a record of the same function being previously determined to be invalid, and if invalidation determinations occur repeatedly for the same reason, it can block additional attempts to activate the function. This history-based operation can be verified by configuring a situation in actual vehicle testing where network retransmission or communication delays are intentionally caused, thereby confirming whether invalidation determination and history storage are performed repeatedly and consistently.

[0147] In this way, the control unit is configured to identify a function token as an invalid token when the function token reuse determination data deviates from the normal range, and to generate a function invalidation signal and simultaneously store the reason for invalidation and the determination time in the function status history data, thereby preventing situations in which the same function is repeatedly activated due to network retransmission, communication delay, or function token duplication based on data.

[0148] A control unit according to one embodiment of the present invention generates functional reliability evaluation data based on the number of times a function is activated, the number of times a function is disabled, and the accumulated time of maintaining a function lock included in the function state history data. The functional reliability evaluation data is calculated based on whether a function disabled signal has been repeatedly generated for the same function within a certain period and the ratio of the time during which the function lock state has been sustained. If the functional reliability evaluation data is determined to be below a reference reliability range, the control unit restricts the generation of a function activation signal for the corresponding function.

[0149] A control unit according to an embodiment of the present invention is configured to generate functional reliability evaluation data based on the number of function activations, the number of function invalidations, and the accumulated time of function lock maintenance included in the function status history data. Here, the function status history data refers to a record of control results accumulated over time for the same vehicle and the same function, and the control unit extracts only items that can be quantitatively calculated from the history data and uses them as basic data for evaluation. The number of function activations refers to the number of times an activation command for the corresponding function was successfully executed during a certain period, the number of function invalidations refers to the number of times a function invalidation signal was generated by function token invalidation determination or policy judgment, and the accumulated time of function lock maintenance refers to the total sum of the time recorded while the function lock state was maintained.

[0150] The control unit calculates time intervals based on the function activation time, function deactivation time, and function lock maintenance time stored in the function status history data to aggregate each of the above items by function. For example, the accumulated time for maintaining the function lock can be calculated by accumulating the time difference between the lock start time and the lock release time, and if the lock state is maintained continuously, the entire period is calculated as a single accumulated time. This calculation method can be verified by confirming whether time records are accumulated consistently without omission through a test in which the function is repeatedly switched between active, deactivated, and locked states during actual vehicle operation.

[0151] The above functional reliability evaluation data is calculated based on whether a function invalidation signal was repeatedly generated for the same function within a certain period and the ratio of the duration of the function lock state. Here, the certain period refers to the time interval during which the control unit evaluates the function state history data. If the number of function invalidations occurring within that period is excessively high compared to the number of function activations, or if the proportion of the accumulated time maintained for the function lock within the total evaluation period is high, the reliability of the corresponding function may be evaluated as low. The control unit may utilize the ratio calculated by comparing the number of function invalidations with the number of function activations or by dividing the accumulated time maintained for the function lock by the total evaluation period as an indicator representing the control stability of the function.

[0152] This calculation method can be verified by configuring and testing normal function usage scenarios and abnormal scenarios involving frequent network errors or token reuse attempts in an actual vehicle environment. For example, in normal scenarios, function invalidation occurs infrequently and the function lock duration is short, whereas in abnormal scenarios, a pattern can be observed where function invalidation signals are repeatedly generated and the function lock state is maintained for a long time. Based on these test results, the control unit can verify whether the function reliability evaluation data reflects actual control stability.

[0153] The control unit controls the generation of a function activation signal for a corresponding function if the calculated function reliability evaluation data is determined to be below the reference reliability range. Here, the reference reliability range refers to the minimum level of reliability at which it is determined that there are no issues with control safety even if the function is activated normally, and the control unit determines whether to allow activation by comparing this reference with the function reliability evaluation data. The restriction on the generation of the function activation signal may be implemented by not immediately generating an activation command even when a function activation request is received, but by maintaining the existing locked state or requiring an additional verification procedure.

[0154] In this way, the control unit aggregates the number of times a function is activated, the number of times a function is disabled, and the accumulated time a function lock is maintained, which are included in the function status history data, based on actual record data, calculates function reliability evaluation data using this, and restricts the generation of function activation signals when the calculated reliability is below a standard range, thereby being configured to control repeated abnormal control attempts for the same function based on data.

[0155] A control unit according to one embodiment of the present invention controls, for a function in which the generation of a function activation signal is restricted according to the function reliability evaluation data, to shorten the integrity verification cycle of the function token and increase the update cycle of temporary random numbers r_v and r_s for generating a function session key, and is configured to re-allow the generation of the function activation signal only when the integrity of the function token re-verified according to the shortened verification cycle and the increased random number update cycle is continuously determined to be normal.

[0156] A control unit according to one embodiment of the present invention is configured to switch control operations in a direction that strengthens security verification procedures for functions in which the generation of a function activation signal is restricted according to the function reliability evaluation data. Here, a function in which the generation of a function activation signal is restricted refers to a function classified so that immediate activation control is not permitted for that function because the previously calculated function reliability evaluation data is determined to be below a reference reliability range. After identifying such a function, the control unit does not repeat the same verification procedure as before even if a subsequent control request for the same function occurs, but rather forms a stricter verification environment by adjusting the verification frequency and the random number update frequency.

[0157] Specifically, the control unit controls the integrity verification cycle of function tokens to be shortened. The integrity verification cycle refers to the time interval or frequency of verification execution in which a post-quantum cryptography-based verification formula is applied to a function token to determine its validity; shortening the cycle means that more integrity verifications are performed within the same time period. For example, if integrity verification was previously performed once at the time of a function request, the control unit can control the system to perform repeated verifications at regular intervals for functions with low reliability. The feasibility of implementing this shortening of the verification cycle can be verified by confirming whether repeated verifications are performed without omissions through testing the continuous reception of function tokens in an actual vehicle environment.

[0158] In addition, the control unit controls the increase of the update cycle for the temporary random numbers r_v and r_s used to generate the function session key. Here, increasing the random number update cycle means reducing the time range for using the same random number value and ensuring that new random numbers are generated and applied at shorter intervals. By controlling r_v generated by the in-vehicle function subscription module and r_s received from the server so that they are not maintained for more than a certain number of times or a certain period of time, the control unit reduces the possibility of the same session key being used repeatedly. This random number update method allows for verification that the session key is effectively changed in accordance with changes in the random number by comparing the session key generation results while gradually reducing the random number generation cycle in an actual communication environment.

[0159] The control unit performs re-verification of function tokens according to the shortened integrity verification cycle and the increased random number update cycle as described above. During the re-verification process, it checks whether function tokens received consecutively for the same function repeatedly pass integrity verification, and does not re-allow function activation based on a single verification result. The control unit is configured to re-allow the generation of a function activation signal for the corresponding function only when all consecutive re-verification results are determined to be normal. Here, "consecutive" refers to a state in which multiple verifications are performed within the shortened verification cycle and all results are determined to be normal.

[0160] This re-authorization procedure can be verified in an actual vehicle test environment by intentionally transmitting a mix of normal and abnormal tokens for functions with low reliability. For example, regarding a function whose reliability has been lowered due to repeated invalidations initially, it can be confirmed whether a function activation signal is regenerated only when a certain number of integrity verifications are consecutively determined to be normal after continuously transmitting only normal function tokens. Through this, it is confirmed that the control unit determines whether to re-authorize based on the accumulation of actual verification results, rather than simply the passage of time.

[0161] In this way, the control unit has a structure that gradually restores the reliability of function control by shortening the integrity verification cycle and increasing the random number update cycle for functions where the generation of function activation signals is restricted according to function reliability evaluation data, and by re-allowing the generation of function activation signals only when the integrity of the function token re-verified under enhanced conditions is continuously determined to be normal.

[0162] A control unit according to one embodiment of the present invention is characterized by identifying a function activation priority for each ECU based on the function status history data and device load value when a function activation signal is simultaneously transmitted to a plurality of ECUs through the Software-Defined Vehicle-based gateway, and controlling the function activation signal to be transmitted sequentially by separating it in time according to the identified function activation priority, thereby preventing function conflicts or temporary malfunctions between ECUs even in a situation where multiple functions are simultaneously activated due to on-demand function subscription.

[0163] A control unit according to one embodiment of the present invention is configured to detect cases where function activation signals are simultaneously transmitted to a plurality of ECUs through the Software-Defined Vehicle-based gateway. Here, the case of simultaneous transmission refers to a situation in which two or more function activation signals are generated for different ECUs at the same time or within a short time interval and transmitted via the gateway. The control unit can identify such simultaneous transmission situations by comparing the generation time information of the function activation signals transmitted to the gateway with the target ECU identification information.

[0164] When a simultaneous transmission situation is identified as described above, the control unit identifies the priority of function activation for each ECU based on the function state history data and device load value. The function state history data is data in which the past active, inactive, and locked states of a function corresponding to each ECU are recorded in chronological order, and the control unit can determine how stably each function has been controlled recently by referring to the history data. For example, if a function corresponding to a specific ECU has recorded repeated deactivation or long-term locking states in the past, the control unit can identify the priority of that function as low. Conversely, a function in which activation and deactivation are normally switched and there is little history of deactivation in the function state history data can be identified as having a relatively high priority.

[0165] The above device load value represents the current load level being processed by each ECU at the time of function activation, and the control unit determines the processing margin of each ECU using the device load value received from the gateway. The device load value can be calculated based on the results of repeated measurements of processing delays and the occurrence of errors at the time of function activation during actual ECU operation tests, and the control unit can identify ECUs with low device load values ​​as priority activation targets by reflecting these measurement results.

[0166] The control unit identifies the function activation priority corresponding to each ECU by considering both functional state history data and device load values. This priority identification does not rely on a single criterion but is achieved by combining historical information indicating past control stability with device load information indicating current processing margin; thus, it can prevent situations where excessive control commands are concentrated on a specific ECU. This priority identification method can be verified by confirming whether the activation sequence is stably separated according to priority through tests that simultaneously activate multiple functions in an actual vehicle environment.

[0167] The control unit controls the sequential delivery of function activation signals by separating them temporally according to the identified function activation priority. Here, separating the delivery temporally means that instead of delivering function activation signals to all ECUs simultaneously at the same time, the signals are delivered sequentially starting with the ECU with the highest priority after a certain time interval. After delivering the function activation signal to the first ECU, the control unit may deliver the function activation signal to the next priority ECU after confirming a response from that ECU or the elapsed of a certain time.

[0168] The feasibility of this sequential delivery method can be verified in actual vehicle control tests by simultaneously generating function activation requests to multiple ECUs and checking the response time and operational status of each ECU. For example, it can be compared and confirmed that communication conflicts or temporary operational delays, which may occur when all functions are activated simultaneously, do not occur with the sequential delivery method.

[0169] In this way, the control unit identifies a situation where function activation signals are simultaneously transmitted to multiple ECUs via a Software-Defined Vehicle-based gateway, identifies the priority of function activation based on function status history data and device load values, and controls the transmission of function activation signals sequentially by separating them in time according to the priority, thereby being configured to prevent function conflicts or temporary malfunctions between ECUs based on data even in situations where multiple functions are simultaneously activated due to on-demand function subscriptions.

[0170] A control unit according to one embodiment of the present invention is configured to generate function control judgment data by combining at least two of the integrity verification result of a function token, the function session key generation result, function state history data, function token reuse determination data, and function reliability evaluation data, and to generate a function activation signal only when the function control judgment data satisfies all of a plurality of independent conditions.

[0171] A control unit according to one embodiment of the present invention is configured to generate function control judgment data by using at least two of the following as input data: a result of verifying the integrity of a function token, a result of generating a function session key, function status history data, function token reuse determination data, and function reliability evaluation data. Here, each data is a result value calculated independently and possesses mutual independence in that it is data generated at different control stages without relying on the same calculation logic or a single indicator.

[0172] The integrity verification result of a function token is data indicating whether the received function token has not been tampered with, and the control unit can determine a normal or abnormal state through procedures such as hash value comparison, signature verification, or checking for consistency with previous verification records for the same token. This verification result can be used based on data confirmed to be normal through testing in an actual communication environment, in which a normal token and a token with some fields modified are repeatedly received.

[0173] The function session key generation result is data indicating whether the function session key generated after the integrity verification of the function token was successfully derived. The control unit can determine a success or failure state by verifying whether all input values ​​required during the session key generation process have been secured and whether the length and format of the generated session key satisfy predefined conditions. For example, the reliability of the function session key generation result can be confirmed by testing whether the same result is reproduced when generating repeatedly with the same input values.

[0174] Function status history data is data in which the past active, inactive, disabled, or locked states of a relevant function are recorded in chronological order, and the control unit utilizes this as a basis for determining whether the currently requested function activation status conflicts with the past history. Through testing that repeatedly activates and deactivates the function in an actual vehicle environment, it can be confirmed that the history data is recorded in chronological order without omission.

[0175] Function token reuse determination data is data indicating whether the same function token has been received repeatedly and whether the difference between the time of reception and the timestamp included in the token exceeds an allowable range; the control unit uses this as a criterion to distinguish between network retransmission or delay situations and token duplication situations. This data can be verified in a test environment where communication delays are artificially induced by determining that normal tokens and reused tokens are identified as different values.

[0176] Functional reliability evaluation data is data reflecting the number of function activations, the number of deactivations, and the function lock duration based on functional status history data, and the control unit utilizes it as an indicator to determine whether the corresponding function has operated stably for a certain period. By comparing cases where errors are intentionally induced with cases of normal operation in actual vehicle control tests, it can be confirmed that the functional reliability evaluation data yields different values.

[0177] The control unit generates function control judgment data by selecting and combining at least two of the above data. In this case, the combination is not a simple single-condition judgment, but is treated as an independent condition considering that each data is a result generated at a different control stage. For example, it can be configured to proceed to the next judgment step only when the integrity verification result of the function token is normal and the function session key generation result is successful; additionally, function token reuse judgment data or function reliability evaluation data can be included to configure the judgment condition.

[0178] Function control judgment data is data that includes whether each of these multiple independent conditions is satisfied, and the control unit controls the generation of a function activation signal only when all conditions are satisfied simultaneously. That is, by not generating a function activation signal when even one of the conditions is not satisfied, it is possible to prevent malfunction based on a single judgment criterion.

[0179] The feasibility and reliability of this configuration can be verified during actual system implementation by confirming that no function activation signal is generated through testing in which each condition is individually set to an abnormal state, and by confirming that a function activation signal is generated only when all conditions are set to a normal state. Through this, it is clearly supported that the control unit is configured to generate a function activation signal based on function control judgment data derived from multiple independent conditions.

[0180] A control unit according to one embodiment of the present invention applies a structure corresponding to an algorithm that determines epicenter reliability using the arrival order and amplitude change of vibration signals collected from a plurality of ground sensors in an earthquake early warning system, and defines the time difference by reception time of the function token, the occurrence order of function token reuse determination data, and the cumulative change amount of function reliability evaluation data as the first time change data, the second order change data, and the third cumulative change data, respectively.

[0181] A control unit according to one embodiment of the present invention applies a structure corresponding to an algorithm that determines the reliability of the epicenter by utilizing the arrival order and amplitude changes of vibration signals collected from a plurality of ground sensors in an earthquake early warning system. Here, the earthquake early warning system has a structure in which a plurality of sensors installed at different locations receive vibration signals regarding the same earthquake event at different time intervals, and determines whether the signal originated from the actual epicenter by comparing the arrival order and amplitude distribution of the signals detected by each sensor. The control unit corresponds this structural concept directly to the functional control domain and is configured to consider temporal, sequential, and cumulative changes together, rather than relying on a single point in time or a single indicator.

[0182] Accordingly, the control unit calculates the time interval between each point in time when a function token is received by the vehicle or server, and defines the pattern of change in this time interval as the first time change data. The first time change data is data that records the difference in reception times between continuously received function tokens; for example, the difference between the reception time of a previous function token and the reception time of a subsequent function token can be calculated and stored in milliseconds or seconds. It can be confirmed that this data exhibits different distributions through repeated reception tests in a normal network environment and tests in an environment where delays are artificially induced, thereby proving that the time change data reflects actual environmental changes.

[0183] In addition, the control unit defines second sequence change data based on the order in which function token reuse determination data occurs. The second sequence change data is data that records, in chronological order, the sequence in which results such as normal determination, suspected reuse determination, and invalid determination occurred for the same function or the same token identifier. For example, cases where reuse determination occurs repeatedly after normal determination and cases where normal determination and invalid determination occur alternately can be distinguished as different sequence patterns. This sequence data can be verified by generating different sequence patterns through tests involving the normal retransmission of a function token and the intentional duplication and transmission of the same token.

[0184] In addition, the control unit defines the cumulative change over time of the functional reliability evaluation data as the third cumulative change data. The third cumulative change data is data that records the pattern of the functional reliability evaluation data increasing, decreasing, or remaining constant over a certain period in the form of a cumulative value; it indicates how the increase in reliability due to an increase in the number of function activations or the decrease in reliability due to function invalidation and function lock maintenance accumulate over time. It can be confirmed that this cumulative change forms different cumulative curves by comparing the case where the function is repeatedly operated normally in an actual vehicle environment with the case where errors are repeatedly generated.

[0185] The control unit treats the first temporal change data, the second sequential change data, and the third cumulative change data as independent change indicators, utilizing them in a structure similar to the method used in earthquake early warning systems to comprehensively determine the signal arrival order and amplitude changes of multiple sensors. In other words, instead of making a judgment based on any single data point, it can be configured to recognize a normal functional control situation only when the temporal change, the sequence of occurrence, and the cumulative change all exhibit a consistent trend together.

[0186] This method of definition and data generation can be verified through tests simulating actual communication and functional operation environments, confirming that each change data is not an arbitrarily set value but is automatically derived based on the actual reception time, determination order, and cumulative results. This supports the configuration that allows a person skilled in the art to clearly understand and implement the first temporal change data, second sequential change data, and third cumulative change data, which are defined and utilized by the control unit in a manner corresponding to the reliability determination structure of the earthquake early warning system.

[0187] A control unit according to an embodiment of the present invention independently identifies whether the first time change data decreases rapidly within a unit time, whether the second sequence change data deviates from a predefined normal sequence, and whether the third cumulative change data increases at a constant slope, and then identifies the function control judgment data as a dangerous state only when abnormal change patterns in two or more of the three data are identified as overlapping within the same time interval, and controls the generation of a function activation signal to be immediately blocked and a function nullification signal to be generated simultaneously when identified as a dangerous state, thereby preventing a situation in which function control is excessively restricted by a false detection of a single condition.

[0188] A control unit according to an embodiment of the present invention processes the first time change data, the second sequence change data, and the third cumulative change data by separating them into independent judgment targets. For the first time change data, the change in the interval between reception points is calculated based on the unit time interval in which function tokens are continuously received, and it is determined whether the interval decreases rapidly compared to the previous interval. Here, whether a rapid decrease occurs can be defined as a case where the difference between two or more consecutive reception interval values ​​is calculated and falls outside the time interval distribution range obtained through repeated testing in a normal communication environment. This definition can be concretized by conducting experiments by configuring a normal network environment and a delay / retransmission environment, respectively, so that a decrease in the time interval is repeatedly observed in actual abnormal situations.

[0189] For the second sequence change data, the control unit aligns the order in which function token reuse determination data occurs on the time axis and compares it with a predefined normal sequence pattern. The normal sequence pattern can be derived based on the process of receiving, verifying, and determining the normality of function tokens in a normal function operation environment, and it can be confirmed that the relative position where reuse determination or invalidity determination occurs exists within a certain range. The control unit may be configured to set a normal sequence range based on sequence data repeatedly collected in actual operation tests and to identify cases that deviate from this range as sequence deviations.

[0190] In addition, the control unit calculates the amount of change in the functional reliability evaluation data accumulated over a certain time interval for the third cumulative change data, and determines whether the accumulated value increases at a constant slope over time. Here, the slope can be defined as the value obtained by dividing the increase in the accumulated value by time; it can be experimentally confirmed that a pattern of gradual increase or stable maintenance is observed in a normal functional operation environment, while a pattern of rapid increase or decrease is observed in situations involving repeated invalidation or lock maintenance. Based on these experimental results, the control unit establishes a normal range for the cumulative change and identifies cases deviating from this range as abnormal cumulative change.

[0191] The control unit independently identifies whether the first time change data shows a rapid decrease, whether the second sequence change data deviates from the normal sequence, and whether the third cumulative change data shows a slope-based change, as described above, and then checks whether abnormal change patterns overlap in two or more of the three data within the same time interval. This overlap can be determined by correlating the determination results of each data based on the same time interval identifier, and is configured so that a single anomaly occurring sporadically in different time intervals is not considered as overlap.

[0192] The control unit identifies the function control judgment data as a dangerous state only when two or more abnormal change patterns are identified as overlapping within the same time interval. When identified as a dangerous state, the control unit immediately blocks the generation of a function activation signal and simultaneously generates a function nullification signal and transmits it to a subsequent function control step. Conversely, the control unit is configured to prevent a situation where function control is excessively restricted by false detection of a single condition by ensuring that it is not judged as a dangerous state when an abnormal change is identified in only one data point or when abnormal changes occur distributed across different time intervals. This judgment structure is concretized to a level that can be implemented by a person skilled in the art, as it is confirmed through tests that reproduce actual communication anomalies, retransmissions, delays, and normal operation situations that a dangerous situation is reliably identified only when there is an overlap of multiple indicators.

[0193] A control unit according to one embodiment of the present invention applies a structure corresponding to a biosignal triage algorithm that determines the level of urgency in stages using the relative change trends of heart rate, oxygen saturation, and respiratory rate in an intensive care unit patient monitoring system, and defines the frequency of the history of generating a function activation signal, the ratio of the occurrence of a function nullification signal, and the ratio of the function lock maintenance time as a first state indicator, a second state indicator, and a third state indicator, respectively.

[0194] A control unit according to one embodiment of the present invention is configured to apply the structural concept of a biosignal triage algorithm utilized in an intensive care unit patient monitoring system to functional control judgment. The biosignal triage algorithm is characterized by observing multiple biosignals with different meanings, such as heart rate, oxygen saturation, and respiratory rate, by separating them into individual indicators, and determining the level of urgency in stages based on the relative change trends and interrelationships over time rather than the absolute values ​​of each indicator. By adopting this structure, the control unit defines state information of different natures directly related to functional control as independent state indicators and comprehensively interprets the patterns of change of these state indicators.

[0195] Specifically, the control unit defines the frequency of function activation signal generation history as the first state indicator. The first state indicator can be calculated as a value aggregated in time units regarding how many times a function activation signal was generated during a specific observation period. For example, the control unit records a timestamp whenever a function activation signal is generated and calculates the frequency by accumulating the number of such records within a continuous observation interval. In this case, the observation period can be set based on the standard where the average activation frequency range is stably formed during normal function usage through repeated testing in an actual vehicle operating environment. Through this, the first state indicator functions not merely as a simple indication of whether an event occurred, but as an indicator reflecting the density and repeatability of function usage.

[0196] The control unit defines the occurrence rate of function invalidation signals as the second state indicator. The second state indicator can be calculated as the ratio of function invalidation signals to the total function control signals generated during the same observation period. To this end, the control unit aggregates the occurrence counts of function activation signals and function invalidation signals, respectively, and calculates the ratio value by dividing the number of function invalidation signals by the total number of signals. This method of calculating the ratio can be derived from the fact that the ratio of function invalidation signals tends to be clearly distinguishable in tests configured with normal subscription environments, abnormal token retransmission, and authentication failure environments. Therefore, the second state indicator is utilized as an indicator that quantitatively reflects the tendency for failure or blocking in the function control process.

[0197] In addition, the control unit defines the ratio of the function lock maintenance time as a third state indicator. The third state indicator can be calculated as the ratio obtained by dividing the cumulative value of the time the function remained locked during the entire observation period by the total observation time. The control unit records the start and release times of the function lock state, respectively, and calculates the lock maintenance time by accumulating the difference between the two times. This calculation method can be designed to distinguish between cases where the function lock operates as a normal security measure in an actual vehicle environment and cases where it is maintained for a long time due to repetitive abnormal situations; furthermore, through repeated testing, it can be confirmed that functional usability deteriorates when the ratio of the lock maintenance time increases beyond a certain level.

[0198] The control unit calculates the first, second, and third state indicators independently, but is configured not to determine immediate function control based on any single indicator alone, but to comprehensively interpret the relative change trends of multiple indicators in a manner similar to a biosignal triage algorithm. Through this structure, the control unit prevents function control from being excessively restricted by temporary anomalies or fluctuations in a single indicator, while enabling the stepwise identification of cases where abnormal trends appear simultaneously in multiple indicators. Since the distinction between normal and abnormal patterns can be confirmed through repetitive operational testing and log analysis, this method of defining and calculating state indicators is concretized to a level that can be directly implemented by a person skilled in the art.

[0199] A control unit according to one embodiment of the present invention is characterized by dividing and comparing the first state indicator, the second state indicator, and the third state indicator by interval according to time order to identify whether the state change between each interval is gradual or abrupt, and if intervals identified as having abrupt state changes occur continuously, automatically switching the judgment criteria of the function control judgment data to an enhanced level, and controlling the generation of the function activation signal to be re-allowed in stages only when a normal state is identified multiple times consecutively under the enhanced judgment criteria, thereby ensuring that the function subscription security control is stably restored according to the temporal trend.

[0200] A control unit according to one embodiment of the present invention manages a first state indicator, a second state indicator, and a third state indicator as data arranged continuously in chronological order, and is configured to divide and compare them into segments having a certain time length. Here, the segment is a time unit set so that function control logs are sufficiently accumulated to determine a state change, and can be set to a range that allows for repeated observation in an actual vehicle operation environment, such as, for example, a few seconds, a few minutes, or a vehicle start-up cycle. The control unit calculates representative values ​​of the first state indicator, the second state indicator, and the third state indicator for each segment, and identifies whether the state change is gradual or abrupt by comparing the difference between representative values ​​of adjacent segments.

[0201] The gradualness or abruptness of a state change can be determined based on whether the amount of change between the previous and current periods for the same indicator falls within the normal change range derived through repeated testing. For example, if the frequency of function activation signal generation history or the rate of function deactivation signal occurrence gradually increases or decreases over time, it is identified as a gradual change; conversely, if it increases or decreases rapidly within a short period, it is identified as an abrupt change. These judgment criteria can be established by analyzing test logs configured for normal operation, temporary communication error, and intentional token reuse situations, respectively, based on the criterion that change patterns between periods are clearly distinguishable.

[0202] The control unit checks, in chronological order, whether sections identified as having abrupt changes occur continuously. If abrupt changes are repeatedly identified within a continuous section, it can be determined that this is highly likely to be a continuous abnormal state rather than temporary noise or a one-time error; therefore, the control unit automatically switches the judgment criteria of the function control judgment data to an enhanced level. An enhanced judgment criterion refers to a standard in which the number of times normal conditions required for generating a function activation signal or the level of continuity requirement is set higher than the existing standard. For example, it may be configured so that a function activation signal is not allowed based on a normal judgment of a single section, but is permitted only when a normal state is repeatedly confirmed across multiple sections.

[0203] Under enhanced judgment criteria, the control unit compares the first, second, and third state indicators for each interval to determine whether a normal state exists, and gradually re-allows the generation of function activation signals only when the judgment result is identified as normal multiple times in a row. Gradual re-allowance can be implemented by gradually restoring the possibility of generating function activation signals over a certain time interval, rather than immediately resuming function activation signals for all functions. This method prevents immediate relaxation of control even when a normal state temporarily appears, and ensures that function subscription control is returned to a normal level only when a stable restoration is confirmed over the temporal trend.

[0204] This structure of time interval division, state change identification, strengthened judgment criteria, and phased re-enforcement can be established based on the results of comparative analysis of normal and abnormal transition sections obtained by collecting long-term logs in actual vehicle operation environments; furthermore, the processing procedures and judgment flows for each stage are clearly defined, allowing a standard technician to implement them as is. As a result, the functional subscription security control is dynamically adjusted according to temporal trends rather than a single point-in-time state, ensuring stable restoration while maintaining a balance between security and usability.

Claims

Claim 1 A mobility-based on-demand function subscription security system comprises a server, wherein the server includes: a storage unit for storing function subscription information for determining the activation or deactivation of a function of an electronic control unit within a vehicle; a control unit for performing operations to verify the integrity of a function token using vehicle identification information, function subscription information, and received post-quantum cryptography-based public key data; and a communication unit for receiving function token data generated in a communication section between the vehicle and the server.The control unit includes, wherein, at the time the vehicle is started, the control unit receives function token data through the communication unit, and verifies the integrity of the function token by combining the vehicle identification information and function subscription information stored in the storage unit with the digital signature and key derivative value included in the function token and substituting them into a post-quantum cryptography-based verification formula, wherein the post-quantum cryptography-based verification formula is configured to use at least one of a Kyber-based parameter verification formula or a Dilithium-based parameter verification formula, wherein the control unit generates a function activation signal to activate the function corresponding to the function subscription information if the verification result according to the post-quantum cryptography-based verification formula is normal, and generates a function invalidation signal to maintain the corresponding function in a locked state if the verification result according to the post-quantum cryptography-based verification formula is abnormal, and wherein, after the integrity verification of the function token is completed, the control unit uses a temporary random number r_v generated by the function subscription module in the vehicle and a random number r_s received from the server to perform a post-quantum-based session key update function SK′ = H(r_v ∥ r_s A mobility-based on-demand function subscription security system characterized by further including the step of generating a new function session key based on vehicle identification information and function subscription information, generating an encrypted control command for a function activation signal using the function session key and transmitting it to a vehicle gateway, wherein the control unit transmits at least one of a function activation signal or a function deactivation signal generated in a state protected by the function session key to a Software-Defined Vehicle-based gateway, determines a function policy condition using current function status data received from the gateway, wherein the function status data is configured to include whether the function is activated, a device load value, and a function policy value, wherein if the function policy condition is satisfied, either an activation command or a deactivation command corresponding to the function is transmitted to the ECU, and if the function policy condition is not satisfied, a policy signal to maintain a function lock state is transmitted to the ECU. Claim 2 delete Claim 3 delete Claim 4 delete Claim 5 A mobility-based on-demand function subscription security system according to claim 1, wherein the control unit generates function state determination data based on the result of verifying the integrity of the function token, whether a function session key is generated, and the result of generating any one of a function activation signal and a function invalidation signal, and generates function state history data by concatenating the function state determination data in chronological order, wherein the function state history data includes a function activation time, a function deactivation time, a function lock maintenance time, and a corresponding function subscription information identifier, and wherein, in the event that a change in function subscription information or a retransmission of the function token occurs for the same vehicle, duplicate function activation and unauthorized reactivation are blocked based on the function state history data. Claim 6 In claim 5, the control unit generates function token reuse determination data by comparing the reception time information of function token data received in the vehicle-server communication section, the number of repeated receptions of the same function token, and timestamp information included in the function token; if the function token reuse determination data deviates from the normal range, the corresponding function token is identified as an invalid token; and if identified as an invalid token, the control unit generates a function invalidation signal and simultaneously stores the reason for invalidation and the determination time in the function status history data, thereby preventing a situation in which the same function is repeatedly activated due to network retransmission, communication delay, or function token duplication. This characterizes a mobility-based on-demand function subscription security system. Claim 7 A mobility-based on-demand function subscription security system characterized in that, in claim 6, the control unit generates function reliability evaluation data based on the number of function activations, the number of function invalidations, and the accumulated time of function lock maintenance included in the function status history data, the function reliability evaluation data is calculated based on whether a function invalidation signal was repeatedly generated for the same function within a certain period and the ratio of the time the function lock state was sustained, and if the function reliability evaluation data is determined to be below a reference reliability range, the control unit restricts the generation of a function activation signal for the corresponding function. Claim 8 A mobility-based on-demand function subscription security system, characterized in that, in claim 7, the control unit controls the function token integrity verification cycle and the update cycle of temporary random numbers r_v and r_s for function session key generation to be shortened for a function for which the generation of a function activation signal is restricted according to the function reliability evaluation data, and is configured to re-allow the generation of a function activation signal only when the integrity of the function token re-verified according to the shortened verification cycle and the increased random number update cycle is continuously determined to be normal. Claim 9 In claim 8, the control unit identifies a function activation priority for each ECU based on the function status history data and device load value when a function activation signal is simultaneously transmitted to a plurality of ECUs through the Software-Defined Vehicle-based gateway, and controls the function activation signal to be transmitted sequentially by separating it in time according to the identified function activation priority, thereby preventing function conflicts or temporary malfunctions between ECUs even in a situation where multiple functions are simultaneously activated due to on-demand function subscription, characterized by a mobility-based on-demand function subscription security system. Claim 10 A mobility-based on-demand function subscription security system according to claim 9, wherein the control unit generates function control judgment data by combining at least two of the function token integrity verification result, function session key generation result, function status history data, function token reuse determination data, and function reliability evaluation data, and is configured to generate a function activation signal only when the function control judgment data satisfies all of a plurality of independent conditions.

Images