In-vehicle network access control system

Abstract

The present invention is characterized in that, in a vehicle internal network access control system, it comprises a user terminal including a display unit; and a user input unit.

Description

Technology Field

[0001] The present invention relates to a vehicle internal network access control system. Background Technology

[0002] Vehicles are equipped with multiple electronic control units that perform braking, steering, power control, body control, infotainment, etc., and these electronic control units control various functions of the vehicle by transmitting and receiving messages to and from each other through an internal vehicle network. Such internal vehicle networks are based on communication structures such as CAN, LIN, FlexRay, and automotive Ethernet, and unlike general IT networks that rely on login sessions with user terminals or external servers, they are characterized by operating in a message-based broadcast or periodic transmission manner.

[0003] Conventional access control technologies have primarily been designed based on session-centric structures such as user authentication, terminal authentication, login session maintenance, and session key management, and presuppose a communication structure capable of maintaining state in a TCP / IP environment. However, in an in-vehicle network environment, the concepts of user login or sessions do not exist, and since each electronic control unit transmits messages independently without maintaining a communication state for an extended period, it is difficult to directly apply such session-based access control methods.

[0004] Consequently, conventional in-vehicle networks face the problem of being unable to accurately determine whether the sender of a message is a legitimate electronic control unit, and to effectively distinguish replay attacks that retransmit previously sent legitimate messages. In particular, when messages with the same message identifier and payload are received repeatedly, it is difficult to determine whether the message follows a normal control flow or has been replayed by an external or internal attack.

[0005] Furthermore, despite the fact that message order may be altered or some messages omitted due to message processing delays or communication errors inherent in in-vehicle networks, conventional technology has not sufficiently established a structure to determine access permission based on the continuity of such communication flow. Consequently, the need for access control technology specialized for in-vehicle network environments has been continuously raised. The problem to be solved

[0006] While presupposing a server structure linked with a user terminal including a display unit and a user input unit, it is configured to perform access control based on the message itself regardless of user login or session maintenance, thereby providing an access control structure suitable for an in-vehicle network environment where the concept of a session does not exist.

[0007] Specifically, the control unit according to the present invention processes messages received from a plurality of electronic control units connected to an internal vehicle network on a message basis rather than a session basis, and identifies the communication flow based on the transmitting ECU identification information, message identifier, message payload, and message reception time included in each message, thereby resolving the problem that conventional session-based access control methods were difficult to apply directly to a vehicle environment.

[0008] Furthermore, the present invention defines a counter value attached to a message received from each electronic control unit as first verification data, and by determining whether the counter of the current message increases based on the counter value of a previously received message, it can effectively identify a replay attack in which the same message is repeatedly retransmitted. Accordingly, by determining the message as a replay message and blocking access when the counter value decreases or repeats with the same value, the vulnerability to message replay attacks that was an issue in the prior art can be structurally improved.

[0009] Furthermore, by configuring the system to identify an abnormal communication flow when the counter value exceeds a predefined maximum increase range, even if the value simply increases, attempts by attackers to bypass access control by arbitrarily manipulating the counter value can also be effectively suppressed. Through this configuration, the present invention can determine various forms of abnormal message flows that may occur in an in-vehicle network environment based on the continuity and increase patterns of the message itself, thereby achieving stable access control effects without separate session management.

[0010] Consequently, the present invention can precisely identify and control the communication flow of an in-vehicle network without relying on user authentication or session maintenance, thereby overcoming the structural limitations of conventional in-vehicle network access control technology and providing an in-vehicle network access control system that has the effect of substantially improving vehicle security. means of solving the problem

[0011] A vehicle internal network access control system according to one embodiment of the present invention is characterized by including a user terminal comprising a display unit; and a user input unit.

[0012] The above-mentioned user terminal includes a server connected to a wired or wireless network, wherein the server includes a communication unit; a storage unit; and a control unit; wherein the control unit is configured to process messages received from a plurality of electronic control units (ECUs) connected to an internal vehicle network on a message basis rather than a session basis, and wherein the control unit identifies a communication flow based on the transmitting ECU identification information, message identifier, message payload, and message reception time included in each message, and determines whether to allow access to the communication flow based on the continuity and temporal validity of the message itself, regardless of the existence of user authentication or a login session.

[0013] The control unit defines a counter value attached to a message received from each ECU as first verification data, sets a counter value included in a previously received message from the same ECU as a reference value, and identifies whether the first verification data has increased monotonically by comparing whether the counter value of the currently received message has increased by 1 or more than the reference value, and the control unit controls the message to block access by determining it as a replay message if the counter value decreases or is received repeatedly with the same value, and the control unit is configured to restrict message reception by the ECU by identifying it as an abnormal communication flow if the counter value increases continuously but exceeds a predefined maximum increase range.

[0014] The control unit defines time information included in each message as second verification data, and calculates the time difference between the message reception time and the message creation time by comparing the second verification data with the server reference time or the vehicle reference time. The control unit identifies the message as a valid message only if the time difference falls within a preset allowable time range, and if it exceeds the allowable time range, controls access by determining the message as a message susceptible to replay attacks via delay or retransmission.

[0015] The control unit creates a sliding window that stores a plurality of recently received messages based on the order of message reception, defines the size of the sliding window by a first window parameter set based on the number of messages, maintains only message identifiers included within the sliding window as valid candidates, and controls the blocking of access to messages containing message identifiers received outside the sliding window by identifying them as messages that have deviated from the communication flow, and is configured to maintain only a continuous communication flow by removing the oldest message identifier and adding a new message identifier at each movement point of the sliding window.

[0016] The above control unit sequentially performs counter-based verification based on first verification data, time-based verification based on second verification data, and sliding window-based verification based on second verification data as independent judgment steps, and the control unit immediately discards any message that fails to pass any of the judgment steps, and the control unit allows only messages that have passed all of the plurality of judgment steps to be used for control signals or state updates between ECUs, thereby preventing message replay attacks even in a vehicle internal network environment where the concept of a session does not exist and performing access control based on the continuity of the communication flow.

[0017] The above control unit is configured to apply different verification intensities depending on the functional type of the ECU transmitting messages on the vehicle internal network, and the control unit defines messages received from ECUs related to braking, steering, and power control as first important messages, and messages received from ECUs related to infotainment or status display as second important messages, and is characterized by differentially applying access control levels according to message importance such that the control unit performs counter-based verification, time-based verification, and sliding window-based verification for the first important messages, and performs at least some of the verifications for the second important messages.

[0018] The control unit is characterized by classifying the ECU as a temporary exclusion target in the list of normal communication ECUs when a message suspected of a replay attack is detected consecutively more than a preset number of times among messages received from a specific ECU, and controlling subsequent messages received from the ECU classified as a temporary exclusion target to be stored in a separate isolation area without reflecting them in the vehicle's internal control logic, and the control unit is configured to determine whether to restore communication of the ECU based on the occurrence frequency, time interval, and counter fluctuation pattern of the messages stored in the isolation area.

[0019] The control unit identifies vehicle operation status information including the starting state, driving state, or stopping state of the vehicle internal network, and variably sets at least one of the size of the sliding window, the allowable time range, or the allowable width of the counter increase according to the vehicle operation status information; the control unit strengthens communication verification conditions by reducing the size of the sliding window or decreasing the allowable time range when the vehicle is in a driving state compared to when it is in a stopping state, and is configured to suppress the possibility of a replay attack in stages according to the vehicle operation situation.

[0020] The above-described control unit is characterized by implementing an access control method dedicated to an in-vehicle network that is structurally distinct from the session-centric access control structure of a TCP / IP-based IT network by performing access control based solely on the counter value, time information, and reception order included in the message, without using user login, session identifier generation, or session maintenance information at all. Effects of the invention

[0021] The present invention provides an access control structure suitable for an in-vehicle network environment where the concept of a session does not exist, by presupposing a server structure linked with a user terminal including a display unit and a user input unit, and by configuring access control based on the message itself regardless of user login or session maintenance.

[0022] Specifically, the control unit according to the present invention processes messages received from a plurality of electronic control units connected to an internal vehicle network on a message basis rather than a session basis, and identifies the communication flow based on the transmitting ECU identification information, message identifier, message payload, and message reception time included in each message, thereby resolving the problem that conventional session-based access control methods were difficult to apply directly to a vehicle environment.

[0023] Furthermore, the present invention defines a counter value attached to a message received from each electronic control unit as first verification data, and by determining whether the counter of the current message increases based on the counter value of a previously received message, it can effectively identify a replay attack in which the same message is repeatedly retransmitted. Accordingly, by determining the message as a replay message and blocking access when the counter value decreases or repeats with the same value, the vulnerability to message replay attacks that was an issue in the prior art can be structurally improved.

[0024] Furthermore, by configuring the system to identify an abnormal communication flow when the counter value exceeds a predefined maximum increase range, even if the value simply increases, attempts by attackers to bypass access control by arbitrarily manipulating the counter value can also be effectively suppressed. Through this configuration, the present invention can determine various forms of abnormal message flows that may occur in an in-vehicle network environment based on the continuity and increase patterns of the message itself, thereby achieving stable access control effects without separate session management.

[0025] Consequently, the present invention provides a vehicle internal network access control system that can precisely identify and control the communication flow of a vehicle internal network without relying on user authentication or session maintenance, thereby overcoming the structural limitations of conventional vehicle internal network access control technologies and having the effect of substantially improving vehicle security. Brief explanation of the drawing

[0026] FIG. 1 is a diagram illustrating the schematic configuration of a vehicle internal network access control system according to one embodiment of the present invention. FIGS. 2 to 5 are drawings illustrating an example of operation of a vehicle internal network access control system according to an embodiment of the present invention. Specific details for implementing the invention

[0027] 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.

[0028] 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.

[0029] 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.

[0030] FIG. 1 is a diagram illustrating the schematic configuration of a vehicle internal network access control system according to one embodiment of the present invention, and FIGS. 2 to 5 are diagrams illustrating an example of the operation of a vehicle internal network access control system according to one embodiment of the present invention.

[0031] Referring to FIGS. 1 to 5, a vehicle internal network access control system according to one embodiment of the present invention includes a user terminal comprising a display unit and a user input unit, and also includes a server connected to the user terminal via a wired or wireless network.

[0032] A vehicle according to one embodiment of the present invention refers to a means of transportation for moving people or cargo in general, and is not limited by the type of power source, driving method, operating environment, or level of automation. For example, the vehicle may include a vehicle with an internal combustion engine as a power source, an electric vehicle with an electric motor as a power source, a vehicle using a hydrogen fuel cell, or a hybrid vehicle in which these power sources are applied in combination. In addition, the vehicle of the present invention may include not only general road vehicles such as passenger cars, trucks, and buses, but also special purpose vehicles, industrial vehicles, construction equipment, agricultural machinery, and autonomous vehicles for logistics transport.

[0033] The vehicle described above may include mechanical components such as a body, chassis, drivetrain, braking system, steering system, and suspension system, and these mechanical components operate in conjunction to ensure the vehicle's driving stability, handling performance, and occupant safety. The body forms the passenger and cargo spaces, while the chassis serves as the basic framework of the vehicle and provides a structure for mounting various mechanical and electronic components. The drivetrain performs the function of transmitting power generated from a power source to the wheels, the braking system controls the vehicle's deceleration and stopping, and the steering system performs the function of controlling the vehicle's direction of travel.

[0034] In addition, the vehicle may include a plurality of Electronic Control Units (ECUs), and each ECU is configured to control a specific function or system of the vehicle. For example, it may include an ECU that controls the output of an engine or motor, an ECU that controls braking force, an ECU that performs steering assistance functions, an ECU that performs body stabilization functions, and an ECU that controls driver convenience functions or infotainment functions. These ECUs transmit and receive data to and from each other through an internal vehicle network and cooperatively control the operating state of the entire vehicle.

[0035] An in-vehicle network is a communication structure provided for communication between electronic control units and is not limited to a specific communication standard or protocol. For example, the in-vehicle network may be composed of CAN, LIN, FlexRay, automotive Ethernet, or a combination thereof, and control signals, status information, sensor data, etc. are exchanged through a message-based communication method. Such communication may be performed periodically or on an event basis, and may be carried out via broadcast or targeting specific nodes.

[0036] Meanwhile, the vehicle may include various sensor devices, and the sensor devices are configured to detect the surrounding environment of the vehicle or the state of the vehicle itself. For example, various types of sensors may be included, such as speed sensors, acceleration sensors, steering angle sensors, braking pressure sensors, temperature sensors, position sensors, cameras, radar, and lidar. Information collected from these sensors can be transmitted to an electronic control unit and utilized for vehicle control, driver assistance, or safety functions.

[0037] Furthermore, the vehicle may include input means for driver operation and output means for displaying vehicle status. Input means may include a steering wheel, pedals, buttons, a touch panel, a voice input device, etc., and output means may include an instrument panel, a display panel, warning lights, an audio output device, etc. These input and output means serve to provide the driver with the vehicle's operating status, warning information, or convenience information.

[0038] The vehicle described in this invention is not limited to the configurations and functions described above and may include various components and functions that may be added or changed in accordance with future technological advancements. Furthermore, depending on the level of automation of the vehicle, fully autonomous vehicles without driver intervention or partially autonomous vehicles including driver assistance functions may also be included in the vehicle concept of this invention, and the vehicle concept of this invention is not limited even if the structure and control method of the vehicle change accordingly.

[0039] A vehicle internal network according to one embodiment of the present invention refers to an overall communication structure formed for transmitting and receiving control signals, status information, or data values ​​among a plurality of electronic control units, sensor devices, actuators, display devices, etc., mounted in a vehicle. The vehicle internal network is not limited to specific communication standards or physical media and can be implemented in various forms depending on the structure, use, or configuration of the electronic system mounted on the vehicle.

[0040] The aforementioned in-vehicle network functions as a foundational infrastructure that enables multiple electronic control units (ECUs) installed in the vehicle to operate independently while performing cooperative control. Each ECU is responsible for specific functions, such as engine or motor control, braking control, steering control, body stabilization, driver assistance, and infotainment control, and coordinates the operation of the entire vehicle by exchanging necessary information with one another through the in-vehicle network. This information exchange can take place in various forms of data, such as sensor data, control commands, status flags, or diagnostic information.

[0041] The in-vehicle network may adopt a message-based communication structure, in which case each electronic control unit transmits or receives data using a predefined message identifier or address scheme. Messages may be transmitted periodically or only upon the occurrence of a specific event, and may be transmitted either to a single receiving node or via a broadcast method delivered simultaneously to multiple nodes connected to the network. This message-based communication structure can be designed to be suitable for control environments within the vehicle that require real-time performance and reliability.

[0042] Furthermore, the aforementioned in-vehicle network may have a complex structure including a physical communication medium and a logical communication layer. As the physical communication medium, a wired medium using electrical signal lines, an optical medium using optical signals, or a combination thereof may be used, and the logical communication layer defines message formats, data encoding methods, error detection methods, etc. This layered structure contributes to ensuring the scalability, maintainability, and interoperability of the in-vehicle network.

[0043] The in-vehicle network may be configured by separating it into multiple network segments based on communication speed, data capacity, and latency characteristics. For example, a network transmitting simple control signals at relatively low speeds and a network requiring large-capacity data transmission may be configured in parallel, and devices performing relay or interlocking functions may be placed between these networks. Through this structure, the in-vehicle network can simultaneously satisfy various functional requirements.

[0044] Meanwhile, the aforementioned in-vehicle network may possess characteristics distinct from external networks. Specifically, it may have a structure that operates primarily on the transmission and reception of individual messages, without relying on user login sessions or long-term stateful connections, and may be characterized by the fact that communication participants are limited to electronic control units defined in advance within the vehicle system. Due to these characteristics, the in-vehicle network requires design considerations different from those of general IT networks.

[0045] The in-vehicle network described in this invention is not limited to the examples given above and may include communication methods, network structures, or control concepts newly introduced in accordance with advancements in automotive electronics technology. Furthermore, even if the components, connection methods, or data processing methods of the in-vehicle network are changed or expanded, the essential concept of a network for performing communication between electronic systems within a vehicle is included in the in-vehicle network of this invention.

[0046] An access control system according to one embodiment of the present invention refers to an overall system provided to determine whether information, signals, or functions are available between a plurality of components or communication entities, and to allow or restrict access based on the result of such determination. The access control system is not limited to a specific industrial field, communication environment, or implementation method, and can be understood as a concept that includes physical access, logical access, or a combination thereof.

[0047] The access control system described above can define and distinguish between the resources, functions, or data subject to access and the entities attempting to access said resources. The access target may be set as a device, a part of a device's function, a data storage area, a communication channel, a control signal, or a service unit, and the access entity may be defined as a user, terminal, process, device, control module, or a combination thereof. Through this distinction, the access control system systematically manages which entities can access which targets.

[0048] An access control system may use one or more criteria to determine whether to allow access. The criteria may include various factors such as identification information of the accessing subject, the time of access, the frequency of access, the access path, the importance of the access target, or the system's operational status, and these factors may be considered individually or in combination. The access control system may store the criteria in the form of reference values, rules, or policies, and determine whether to allow access by comparing the request with the criteria whenever an access request occurs.

[0049] In addition, the access control system may perform various additional operations before or after the point at which an access request occurs. For example, these operations may include generating logs to record access requests, imposing restrictions based on the number of access attempts, outputting warnings for abnormal access attempts, or changing the status of the accessing entity. These additional operations serve to enhance the reliability and stability of the access control system.

[0050] The access control system can be implemented in a centralized or distributed structure. In a centralized structure, a single control device or server performs access determination, while in a distributed structure, multiple devices or modules can perform access control according to their respective determination criteria. Furthermore, the access control system can be implemented using hardware components, software components, or a combination thereof, and the access determination logic can be stored in the form of firmware, program code, or configuration information.

[0051] Meanwhile, the access control system may include not only static access policies but also dynamic control functions that can modify access policies according to system operating conditions or environmental changes. For example, access policies can be adjusted by narrowing or expanding the scope of allowed access based on specific time periods, conditions, or the occurrence of specific events. Through these dynamic control functions, the access control system can flexibly respond to various operating environments.

[0052] The access control system described in this invention is not limited to the configuration and operation described above, and new judgment criteria, control methods, or components may be added or modified depending on technological advancements or changes in the application environment. Even if the access target, accessing entity, judgment criteria, or control method changes, the essential concept of a system that determines and controls whether access is possible is included in the access control system of this invention.

[0053] A user terminal (100) according to one embodiment of the present invention includes, for example, a personal computer, a server computer, a handheld or laptop device, a mobile device (mobile phone, PDA, media player, etc.), a multiprocessor system, a consumer electronic device, a mini computer, a mainframe computer, a distributed computing environment including any of the aforementioned systems or devices, and an edge computing environment in which data is processed at the edge where data is generated rather than at a central server, and the configuration is not limited only to what is described.

[0054] The user terminal (100) 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), and may have multiple cores.

[0055] The 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 (100) may include additional storage. The storage includes, but is not limited to, magnetic storage, optical storage, etc. The storage may store computer-readable instructions for implementing one or more embodiments disclosed herein, and may also store 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.

[0056] Additionally, the user terminal (100) may include a user input unit (110) and an output device. The user input unit (110) 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 the user input unit (110) or 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.

[0057] Each component of the user terminal (100) may be connected by various interconnections such as a bus (e.g., peripheral component interconnection (PCI), USB, firmware (IEEE 1394), optical bus structure, etc.) or may be interconnected by a network. Terms such as “component,” “system,” etc. used in this specification generally refer to computer-related entities that are hardware, a combination of hardware and software, software, or running software.

[0058] A user terminal (100) according to one embodiment of the present invention may include a display unit (120), and the method of implementing the display of the display unit (120) is not limited and may be implemented in 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 (120) includes a liquid crystal display panel, a backlight unit that supplies light to the liquid crystal display panel, and a panel driving unit that drives the liquid crystal display panel. Meanwhile, the display unit (120) may be implemented as an OLED panel, which is a self-emissive element, without a backlight unit.

[0059] A server (200) according to one embodiment of the present invention may include a communication unit (210), a storage unit (220), and a control unit (230).

[0060] A communication unit (210) according to one embodiment of the present invention can communicate with a user terminal (100) or other external electronic devices, etc., via wired or wireless communication methods. Therefore, in addition to a connection unit including a connector or terminal for wired connection, it can be implemented in various other communication methods. For example, it can 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 (210) 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). Additionally, the communication unit (210) can be implemented in the form of a device, a software module, a circuit, a chip, etc.

[0061] A communication unit (210) 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 (210) 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.

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

[0063] A control unit (230) according to one embodiment of the present invention can perform control for the operation of various components of a server (200). The control unit (230) 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 (200).

[0064] 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 in the server (200) at the time of manufacturing the server (200), or may be installed in the server (200) based on the received data by receiving data of the application from an external source when it is used later. The data of the application may be downloaded to the server (200) 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 (230) may be implemented in the form of a device, S / W module, circuit, chip, etc., or a combination thereof.

[0065] A control unit according to one embodiment of the present invention is configured to process messages received from a plurality of electronic control units (ECUs) connected to an internal vehicle network on a message-by-message basis rather than a session basis. Here, processing on a message-by-message basis rather than a session basis means a method of receiving, judging, and processing each message by treating it as an independent processing unit, without establishing or managing logins, connection maintenance, state synchronization, or session identifiers between communication partners.

[0066] Specifically, the control unit is configured to recognize each message received on the vehicle's internal network as a single individual event at the time of reception. To this end, when the control unit receives a message, it first breaks the message down into byte units or field units to identify the data areas constituting the message. At this time, the message may be recognized as having a structure that includes at least some of the following: identification information for identifying the transmitting ECU, an identifier indicating the type or purpose of the message, a payload containing actual control or status information, and time information regarding the time at which the message was received. The control unit treats each of these components as the minimum unit data required for message-unit processing.

[0067] In processing the above message, the control unit does not create or reference a communication session logically connected to a previously received message. Instead, even if a message is received repeatedly from the same ECU, each message is read individually, and the processing is determined based on the order in which the message was received, the time of reception, and the included data value itself. For example, the control unit stores messages continuously received from a specific ECU in an internal buffer, but this storage is limited to recording purposes for performing order comparison or value comparison between messages, rather than for maintaining a session state.

[0068] Furthermore, the control unit does not generate or manage state information, such as whether the communication connection is maintained, the length of the connection, or whether the connection has been terminated, during the message processing process. In other words, it assumes that whether a message has been successfully received is already determined at the physical or link layer, and the control unit executes processing logic at the higher processing stage based solely on the message content itself. Due to this structure, even when the network connection is temporarily interrupted and then resumed, the control unit can immediately recognize and process the next received message as a new message without any separate reconnection or session recovery procedures.

[0069] When messages are received from multiple electronic control units, the control unit may manage each message by classifying it according to the transmitting ECU; however, this does not constitute session management but rather corresponds to classification processing for identifying the message source. For example, the control unit stores message reception history by ECU identification information, but this is used only as reference data to check the trends or repetitions of messages received from each ECU, and is not used to maintain the communication status with a specific ECU or to sustain a connection.

[0070] Such a message-unit processing structure can be easily implemented by a typical technician in an in-vehicle network environment. For example, the control unit can be implemented to receive messages via interrupt or polling whenever it receives a message from the ECU, sequentially load the received messages into a queue, and then retrieve, parse, and process messages one by one from the queue. In this case, each message loaded into the queue is treated as an independent data object, and the results of processing a previous message are not used as a prerequisite for processing subsequent messages.

[0071] With this configuration, the control unit can flexibly respond on a message-by-message basis without resetting or recovering communication sessions, even in situations where message loss, reordering, or temporary communication interruptions may frequently occur due to the characteristics of the vehicle's internal network. Furthermore, since additional memory structures or state management logic for storing or managing session information are unnecessary, it can be implemented with a relatively simple structure even in automotive embedded environments and can operate stably in actual vehicle environments.

[0072] A control unit according to an embodiment of the present invention identifies a communication flow based on the transmitting ECU identification information, message identifier, message payload, and message reception time included in each message, and is configured to determine whether to allow access to the communication flow based on the continuity and temporal validity of the message itself, regardless of the existence of user authentication or a login session. Here, identifying a communication flow means not merely treating multiple messages as individual data, but tracking the order and interval at which identical or related messages are received over time, and organizing them into a state where it is possible to determine whether they correspond to normal control operations.

[0073] Specifically, whenever a message is received from the vehicle's internal network, the control unit identifies the sender of the message by referring to the transmitting ECU identification information included in the message. The transmitting ECU identification information is an identification value uniquely assigned to each ECU and may be included in the message header area or a predefined data field; the control unit uses this information to classify and manage messages by ECU. In this case, classification is not intended to create or maintain sessions, but is used as a criterion for comparing the temporal order of messages received from the same ECU.

[0074] The control unit also uses a message identifier to identify the control function or transmission purpose that the message intends to perform. The message identifier can be set as a value to distinguish the type of message, such as braking control, status reporting, or sensor value transmission, and the control unit can identify patterns in which messages of the same type are repeatedly received based on the message identifier. Through this, the control unit can determine, using accumulated data, the typical transmission frequency of messages with a specific message identifier from a particular ECU.

[0075] The message payload is a data area containing actual control or state values, and the control unit interprets the payload to determine the control commands or state changes implied by the message. In this case, rather than directly determining whether access is permitted based on the payload value itself, the control unit can indirectly determine whether the message was generated according to a normal control flow by comparing changes in the payload value corresponding to the same message identifier. For example, if the payload value in a sequence of messages changes gradually within a physically possible range, it may be considered a normal flow; however, if a payload exactly identical to the previous message is abnormally and repeatedly received, it may be recognized as a communication flow anomaly.

[0076] The control unit records time information for each message based on the time of message reception. The time information is a value indicating the time when the message reaches the control unit and can be recorded using the system's internal clock or the vehicle's reference time. The control unit determines whether the messages are being received within a normal cycle by calculating the time interval between the reception times of consecutive messages corresponding to the same ECU and the same message identifier. For example, if it is confirmed through repetitive data that a specific message is received at an average interval of 10ms, the control unit can determine temporal validity by comparing whether the reception interval of subsequent messages deviates significantly from that average value.

[0077] In this communication flow identification process, the control unit does not refer to any session-related information, such as user authentication information, login session identifiers, or connection maintenance status. In other words, information such as which user initiated the message or how long the communication connection has been maintained is not used to determine whether access is permitted; instead, the decision is made based solely on the relationship between the information contained within the message itself and the time of message reception. Accordingly, even if communication is temporarily interrupted and then resumed, the control unit does not regard the new message as an extension of the previous session but can immediately include it in the communication flow analysis as an independent message.

[0078] The continuity of the message itself refers to whether the sequence of messages arranged based on the same ECU and the same message identifier flows naturally over time. The control unit arranges messages in the order of their reception and determines continuity by checking for any reversal of order or abnormal repetition between previous and subsequent messages. For example, if a pattern in which messages with the same message identifier are repeatedly received at regular intervals from the same ECU is sufficiently observed, the control unit stores this as a reference pattern and compares it to determine whether subsequently received messages exhibit a significantly different order or interval from that pattern.

[0079] Temporal validity refers to whether the time at which a message is received falls within the time range in which the message holds meaning. Based on message reception time data collected in the past, the control unit can set an acceptable reception time range for a specific message identifier. This range can initially be derived by analyzing message logs repeatedly collected during the vehicle manufacturing or test drive process; for instance, it can be implemented by calculating the average and variance of time intervals during which the same message is repeatedly received, and setting a standard deviation range that is a certain multiple of the average value as the acceptable range. Since this data is accumulated based on logs collected in an actual vehicle driving environment, it can be used as a standard formed by repeatedly observed data rather than an arbitrarily set value.

[0080] The control unit determines whether to allow access by synthesizing the results of the continuity and temporal validity judgments mentioned above. For example, if a message is received in a normal order within the same ECU, the interval between reception times falls within the allowable range, and changes in the payload value do not deviate significantly from the existing pattern, the control unit determines that the message is included in the normal communication flow and allows access. Conversely, if the same message is abnormally repeated, the reception time significantly exceeds the allowable range, or the message order is reversed, the control unit determines that the message is out of the communication flow and may restrict access.

[0081] This configuration can be fully implemented by a standard technician collecting message logs within the vehicle's internal network environment and analyzing message reception intervals, repetition patterns, and sequence relationships based on those logs. In particular, since all criteria used for judgment are derived from information extractable from the messages themselves and data repeatedly collected during actual vehicle operation, this can be realized without relying on additional external information or abstract variables. Consequently, the control unit can clearly identify communication flows at the message level even in an environment without a session concept and reliably determine whether to allow access based on those flows.

[0082] A control unit according to one embodiment of the present invention defines a counter value added to a message received from each ECU as first verification data, sets a counter value included in a message previously received from the same ECU as a reference value, and identifies whether the first verification data has increased monotonically by comparing whether the counter value of the currently received message has increased by 1 or more than the reference value.

[0083] Here, the counter value refers to an integer data that is appended to a message whenever each ECU generates a message, and is used to indicate the order in which messages are generated.

[0084] Specifically, when each ECU transmits a message, it refers to an internally maintained counter variable to include the current counter value in a specific field of the message. This counter variable can be set to increment by 1 whenever the ECU generates a message, and can be reset to its initial value when power is reapplied or the ECU is reset. This counter value may be included in part of the message payload or in a specific bit area of ​​the message header, and the control unit can extract the corresponding location by parsing it according to predefined rules.

[0085] When the control unit receives a message from the ECU, it first reads the counter value included in the message and stores it as first verification data. Subsequently, the control unit refers to a previous message containing the same ECU identification information and sets the counter value included in that previous message as a reference value. This reference value is the counter value of the last message successfully received from the same ECU and can be stored in the control unit's memory or storage area in conjunction with the ECU identification information. At this time, the information stored is limited to the counter value of the previous message itself, rather than the session state.

[0086] The comparison between the counter value of the currently received message and the reference value can be performed through a simple integer comparison operation. For example, if the reference value is N, monotonically increasing can be determined by checking whether the counter value of the currently received message is N+1 or greater. This comparison process can be implemented in the form of a conditional statement, such as if (current_counter >= previous_counter + 1). Since this comparison operation does not require a separate mathematical model or complex calculations, it can be easily realized even in automotive embedded control environments.

[0087] Identifying monotonic growth means verifying whether the counter values ​​of messages received from the same ECU do not decrease over time, do not repeat at the same value, and increase by at least 1 compared to the previous value. The control unit may determine that the message does not follow the normal generation order if the current counter value is smaller than the reference value or is equal to the reference value. This corresponds to a typical pattern that can occur when a previously transmitted message is retransmitted exactly as is, or when an attacker duplicates a message and transmits it repeatedly.

[0088] The reason for using the criterion of whether the counter value has increased by 1 or more is that message loss or communication delays may occur in an actual vehicle internal network environment. For example, if a message with a counter value of 101 is not received normally and is lost when the reference value is 100, the counter value of a subsequently received message may become 102. Even in this case, the control unit can accommodate the normal communication flow without unnecessarily blocking it by setting the monotonic increase condition to an increase of 1 or more. This criterion can be set based on data obtained by repeatedly observing the frequency of message loss and the counter increase pattern during actual vehicle driving.

[0089] As a practical implementation example, during a vehicle test drive, a specific ECU is configured to transmit messages at a certain frequency per second, and the control unit records the counter values ​​of the received messages in chronological order. Through this recording, it can be confirmed that the counter difference between consecutive messages is mostly distributed within the range of 1 or 2; based on these observations, cases where the counter value increases by more than 1 compared to the previous value can be defined as the normal range. Since such data can be collected repeatedly under various driving conditions and communication load situations rather than through short-term experiments, it can be used as a verified standard in a real environment rather than under arbitrarily set conditions.

[0090] The control unit identifies whether the first verification data is monotonically increasing based on these comparison results, and then utilizes this as basic data to determine whether the message belongs to a normal communication flow. At this stage, the control unit determines only whether the counter value is monotonically increasing, while other time information or message sequence information may be additionally considered in a separate step. In other words, in this step, the judgment is made based solely on the relationship between the counter value included in the message and the counter value of the previous message.

[0091] With this configuration, a person skilled in the art can easily implement counter-based monotonically increasing verification by setting each ECU to include a counter value in the message, and having the control unit store the previous counter value for each ECU and perform a simple comparison operation. Since the data used for judgment is limited to the value included in the message itself and the value already obtained from the previous message, it can be realized without additional external data collection or complex learning processes, and can be applied in a manner sufficiently verified through iterative experiments and observations in an internal vehicle network environment.

[0092] A control unit according to one embodiment of the present invention controls access by determining the message as a playback message and blocking access when the counter value decreases or is repeatedly received at the same value, and is configured to restrict the reception of messages by the corresponding ECU by identifying it as an abnormal communication flow when the counter value continuously increases but exceeds a predefined maximum increase range.

[0093] Here, a replay message refers to a message that was previously transmitted normally and is received again while maintaining the same counter value, or a message received with a counter value smaller than that of a previously received message, which can be identified by the fact that it does not follow the normal message generation order.

[0094] Specifically, for messages continuously received from the same ECU, the control unit maintains the counter value of the immediately preceding message that was processed normally as a reference value. If the counter value of a subsequently received message is smaller than the reference value, it can be determined that the message is a retransmission of a message generated at a past point in time. Additionally, if the counter value of the currently received message is equal to the reference value, it can be determined that the same message has been transmitted redundantly or duplicated and retransmitted. The control unit classifies all such cases as replay messages and restricts access by immediately discarding or blocking the messages to prevent them from being delivered to the vehicle's internal control logic.

[0095] Such a determination can be implemented using simple integer comparison operations. For example, if the counter value of the previous message is stored as prev_counter and the counter value of the current message is extracted as curr_counter, the system can be implemented to determine that the message is a replay message if the condition if (curr_counter <= prev_counter) is satisfied. Since this comparison does not require a separate statistical model or complex calculations, a person of ordinary skill can easily implement it even in a vehicle microcontroller environment.

[0096] Meanwhile, the control unit does not consider it a normal communication flow even if the counter value increases continuously without decreasing or repeating, if the increase exceeds a predefined maximum increase. Here, the maximum increase refers to the upper limit of the difference in counter values ​​that can occur between two consecutive messages during the process of the same ECU normally generating and transmitting messages. Based on this maximum increase, the control unit identifies cases where an excessively large counter jump occurs as abnormal communication flows.

[0097] The maximum increment is not an arbitrarily set value, but can be derived based on message log data repeatedly collected in an actual vehicle environment. For example, during a vehicle test drive, a specific ECU is configured to transmit messages at regular intervals, and the control unit records the counter values ​​of the received messages in chronological order. Analyzing this record reveals that under normal communication conditions, the counter difference between consecutive messages mostly remains at a level of 1 or 2, and even when communication delays or message loss occur, the difference is distributed within a limited range. Based on this actual data, the maximum increment can be set based on the maximum value or upper range value of the observed counter differences.

[0098] For example, if it is confirmed through repeated experiments that the counter difference between consecutive messages is concentrated in the range of 1 to 5, the control unit may set the maximum increase to 5 or a value slightly greater than that. If the counter value in a subsequently received message increases by 10 or more than the reference value, this may be determined as an abnormal increase that is difficult to explain as normal message loss or delay. The control unit may implement this determination using a conditional statement such as if (curr_counter > prev_counter + max_delta), where max_delta corresponds to the maximum increase.

[0099] If the control unit determines that the increment of the counter value exceeds the maximum increment limit, it identifies the message as an abnormal communication flow rather than simply classifying it as a replay message. This may apply to cases where an attacker attempts to bypass access control logic by artificially increasing the counter value significantly, or where the counter value is abnormally altered due to an internal state anomaly in the ECU. Accordingly, the control unit may apply additional restriction measures not only to the relevant message but also to all subsequent messages received from the ECU.

[0100] Specifically, the control unit can set a message reception restriction state for an ECU identified as having an abnormal communication flow, and control the exclusion of messages received from the ECU from processing for a certain period of time or isolating and storing them in a separate buffer area. Even in this process, the control unit does not use concepts such as session blocking or connection termination, but restricts reception simply by excluding messages from the ECU during the message processing stage.

[0101] Such determinations regarding counter decrement, repetition, and exceeding the maximum increment are all performed using only the relationship between the counter value contained in the message itself and the counter value of the immediately preceding message. Since the data used for the judgment criteria can be established based on distribution characteristics confirmed through message logs repeatedly collected in actual vehicle driving and test environments, a person skilled in the art can implement this in the same manner by collecting and analyzing such data. Therefore, this configuration can be reproducibly implemented based on procedures verified by actual communication patterns, rather than through arbitrary setting of criteria.

[0102] A control unit according to one embodiment of the present invention defines time information included in each message as second verification data, and calculates the time difference between the time of message reception and the time of message creation by comparing the second verification data with the server reference time or the vehicle reference time.

[0103] Here, time information refers to a value recorded by the ECU that generated the message at the time of its creation and included in the message, which is data indicating when the message was generated. This time information can be expressed as an integer or fixed-point value with a resolution of at least one of seconds, milliseconds, or microseconds, and can be included in the message header area or a predefined data field.

[0104] Specifically, when each ECU generates a message, it obtains the current time value from an internal clock or a common vehicle clock and records it in the message's time information field. The clock used at this time may be any one of a timer installed inside the ECU, a reference time shared through a vehicle network, or a reference clock provided by the vehicle control system. Upon receiving a message, the control unit parses the time information field included in the message to extract a value indicating the time of message generation and stores it as second verification data.

[0105] The control unit also separately records the time at which the message is received. This reception time can be defined as the moment the message is input through the control unit's communication interface, and is measured based on either the server reference time or the vehicle reference time. The server reference time refers to the reference time internally maintained by the server constituting the access control system, while the vehicle reference time refers to the reference time commonly used throughout the entire vehicle system. Depending on the system configuration, the control unit may select either of these to use as the reference time.

[0106] The calculation of the time difference can be performed by simply subtracting the time value at the time of message generation from the time value at the time of message reception. For example, if the time information included in the message is t_gen and the reference time at the time of message reception is t_recv, the control unit can calculate the time difference through an operation such as delta_t = t_recv - t_gen. Since this operation corresponds to a simple arithmetic operation, a person skilled in the art can easily implement it in an embedded control environment without a separate complex algorithm.

[0107] The purpose of the control unit calculating the time difference is to quantitatively determine the interval between the time a message is generated and the time it is actually received. In a normal vehicle internal network environment, messages generated by the same ECU are transmitted through the network immediately after generation and reach the control unit within a relatively short period of time. Therefore, by analyzing repeatedly collected message logs, the control unit can identify the distribution of time differences generally observed for specific ECUs and specific message identifiers.

[0108] For example, during a vehicle test drive, a specific ECU is configured to generate messages at a 10ms interval, and the control unit records the generation time and reception time of each message. Analyzing these records reveals that the time difference for most messages is concentrated within the range of 1ms to 3ms, and it can be observed that even when network load increases or temporary delays occur, the value tends to remain within a certain range. Through these repeated measurement results, the range in which a time difference can normally occur is naturally derived from the actual data.

[0109] The control unit maintains the time difference calculated in this manner as second verification data and can utilize it as basic data to determine whether the message was delivered in accordance with the normal time flow in a subsequent stage. In this case, the criteria for determining the time difference are not set arbitrarily, but can be formed based on relationship data between the message creation time and the reception time repeatedly collected in an actual vehicle environment. Therefore, a person skilled in the art can collect message logs in the same manner and calculate the time difference and set verification criteria by comparing the creation time and reception time included in the logs.

[0110] With this configuration, the control unit can quantitatively determine the degree of message delivery delay solely through a simple comparison between the time information contained in the message and the reference time, and can evaluate the temporal characteristics of the message without referring to separate user authentication information or session status. Since all data used for judgment is limited to the time information contained in the message itself and the reception time information directly recorded by the control unit, the implementation is simple, reproducible, and configured in a way that is fully feasible in an actual in-vehicle network environment.

[0111] A control unit according to an embodiment of the present invention identifies a message as a valid message only when the time difference falls within a preset allowable time range, and controls access by determining the message as a message susceptible to replay attacks via delay or retransmission when the time difference exceeds the allowable time range. Here, the allowable time range refers to the range of time difference that can occur in a normal vehicle internal network environment between the time the message is generated and the time it is received by the control unit, and is used as a reference value for determining whether the message is properly delivered.

[0112] Specifically, the control unit maintains the time difference between the message generation time and the message reception time calculated in the preceding step as a single numerical value. This time difference can be measured repeatedly for the same ECU and the same message identifier, and the control unit can manage the cumulative distribution of such time differences using message logs collected during vehicle test drives, system operation tests, or normal operation. For example, in a situation where a specific ECU periodically generates messages, the control unit records the generation time and reception time for each message and stores the difference between them in chronological order.

[0113] By analyzing the accumulated time difference data, the control unit can identify the range of time differences observed in a normal communication environment. In an actual vehicle environment, time differences are not completely constant due to factors such as network load, ECU processing delay, and communication medium characteristics; however, repeated measurements show that most time differences tend to concentrate within a certain range. Based on these repeated observation results, the control unit can set an allowable time range based on the maximum value or the upper range value of the observed time differences.

[0114] For example, if it is confirmed that the time difference repeatedly measured for the same message is mostly distributed in the range of 1ms to 4ms and up to 6ms is observed in some situations, the control unit may set the allowable time range to 6ms or a slightly larger value. Since such a value can be derived based on log data repeatedly collected under various driving conditions and communication load situations rather than a single experiment, it can be used as a reproducible standard in a real environment.

[0115] The control unit compares the calculated time difference for each message received thereafter with the aforementioned allowed time range. This comparison can be implemented using a simple numerical comparison operation, for example, through a conditional statement such as if (delta_t <= allowed_time). If the time difference falls within the allowed time range, the control unit determines that the message was transmitted via a normal path immediately after generation and identifies it as a valid message. Only when identified as a valid message can the message be delivered to the vehicle's internal control logic or a subsequent processing step.

[0116] Conversely, if the time difference exceeds the allowed time range, the control unit determines that the message has deviated from the normal real-time communication flow. This may correspond to situations where a message has been stored for a long time after creation and then retransmitted, or where a previously generated message has been reinjected by external or internal factors. The control unit classifies such messages as vulnerable to replay attacks caused by delays or retransmissions, and blocks access to prevent the message from being used for control signals or state updates.

[0117] Access blocking can be performed by discarding or ignoring the relevant message during the message processing phase, rather than through methods such as session termination or connection disconnection. In other words, the control unit controls the process by removing messages that have exceeded the allowed time range from the internal processing queue or recording them in a separate log area, ensuring they are not passed to the control logic. Even in this process, the control unit does not refer to user authentication information or login status, but makes decisions based solely on the relationship between the message's time difference value and the allowed time range.

[0118] Such an allowable time range-based judgment structure can be fully implemented by a person of ordinary technical expertise within a vehicle's internal network environment. The data used for judgment is limited to creation time information contained within the message itself and reception time information directly recorded by the control unit, and the allowable time range can also be derived from time difference data repeatedly collected during actual vehicle operation and testing. Therefore, the allowable time range is not an arbitrarily set value but can be established based on data verified in an actual communication environment, thereby enabling the effective identification and blocking of messages susceptible to replay attacks resulting from delays or retransmissions.

[0119] A control unit according to one embodiment of the present invention creates a sliding window that stores a plurality of recently received messages based on the message reception order, and defines the size of the sliding window as a first window parameter set based on the number of messages.

[0120] Here, a sliding window refers to a logical storage structure for maintaining and managing a certain number of recent messages in sequence; it is a data management unit configured purely based on the number of received messages, rather than being defined by time length or session duration.

[0121] Specifically, whenever a message is received from the vehicle's internal network, the control unit sequentially writes the message to an internal storage area in the order of receipt. At this time, the control unit arranges each message in the order of its reception time, clearly maintaining the order from the first received message to the most recently received message. This arrangement can be implemented in the form of an array data structure, a linked list, or a circular buffer, and a person skilled in the art can select and implement a memory structure suitable for an automotive embedded environment.

[0122] The size of the sliding window is defined by the first window parameter, which represents the maximum number of messages that can be maintained simultaneously within the sliding window. For example, if the first window parameter is set to 50, the control unit is configured to maintain the 50 most recently received messages within the sliding window. Whenever a new message is received, the control unit adds that message to the last position of the sliding window, and if the number of messages already stored in the sliding window exceeds the first window parameter, it automatically removes the oldest received message.

[0123] Through this operation, the sliding window continuously moves according to the order of message reception. That is, whenever a new message is received, the window moves forward one step, maintaining a structure that always contains only the most recently received messages. In this process, the control unit preserves the relative reception order of messages, thereby clearly identifying the sequential relationship of messages continuously received by the same ECU.

[0124] The first window parameter is not an arbitrarily set value, but can be configured based on message reception characteristics observed in the actual vehicle internal network environment. For example, the number of messages received per second from a specific ECU or the entire network during a vehicle test drive can be recorded, and the amount of message reception repeatedly observed over a certain period during normal driving can be analyzed. Through this analysis, the first window parameter can be configured by considering both the minimum number of messages required to determine a normal communication flow and the upper limit of the number of messages to prevent excessive memory usage.

[0125] As an example of actual implementation, the control unit accumulates and records the number of messages received in intervals of a set time while the vehicle is operating normally, and can confirm from the record that most intervals contain a number of messages within a specific range. For instance, if it is observed that an average of 30 to 40 messages are received during the last 100ms as a result of repeated measurements, the control unit can sufficiently cover the normal message flow by setting the first window parameter to approximately 50. This value can be verified not by a single condition, but by data collected repeatedly under various driving conditions and network load situations.

[0126] By creating a sliding window, the control unit can efficiently manage the set of recent messages necessary to determine communication flow without storing all previously received messages indefinitely. Furthermore, by defining the size of the sliding window based on the number of messages, message sequence-based processing is possible without being affected by time synchronization errors or clock differences between ECUs.

[0127] Since such a sliding window creation and first window parameter definition structure is implemented based on clear criteria regarding the order and number of message receptions, a person skilled in the art can easily perform it using only the basic functions of receiving and storing messages in the vehicle's internal network. As all data used for judgment and management is limited to the actual received messages and their reception order, it can be implemented reproducibly without additional external data or abstract conditions.

[0128] A control unit according to one embodiment of the present invention maintains only the message identifier included within the sliding window as a valid candidate, and controls the blocking of access to a message containing a message identifier received outside the sliding window by identifying it as a message that has deviated from the communication flow. Here, a message identifier is identification information included in a message frame to distinguish each message in an internal vehicle network, and may include at least one of a CAN ID, a header field of an Ethernet frame, or a message code defined in a higher-level protocol. Since such a message identifier is used repeatedly in association with the sender, functional purpose, or control target of the message, it can be utilized as reference information for determining the communication flow.

[0129] The control unit extracts the message identifier included in each message constituting the sliding window and maintains the extracted message identifier as a set of valid identifiers in an internal storage area. At this time, the set of valid identifiers is a set of identifiers derived from the messages currently contained within the sliding window and is dynamically updated as the sliding window moves. For example, if the size of the sliding window is set to 50 by the first window parameter, the control unit constructs the set of valid identifiers based on the message identifiers included in each of the 50 most recently received messages.

[0130] Whenever a new message is received, the control unit compares the message identifier contained in the message with the set of valid identifiers within the sliding window. This comparison can be performed by a simple determination of inclusion, and can be implemented, for example, through array searching, hash table lookups, or bitmap comparisons. A person skilled in the art can select the most suitable data structure considering ECU performance and memory constraints. If the message identifier of the received message is included in the set of valid identifiers within the current sliding window, the control unit recognizes the message as a message that is continuously included in the existing communication flow.

[0131] Conversely, if the message identifier of a received message is not included in the set of valid identifiers within the sliding window, the control unit identifies the message as a message that has deviated from the communication flow. This applies when an identifier that has not been observed in a certain number of recent message flows suddenly appears, signifying a situation where there is a possibility that it is a retransmission, delayed transmission, or externally inserted message that has deviated from the normal communication order. The control unit classifies such messages as targets for access blocking and processes them so that they are not delivered to control logic or state update processes between ECUs.

[0132] Since such identification is performed by a simple comparison of message identifiers, it can be implemented without interpreting the message content or payload. Consequently, the control unit can determine in real-time whether there is a deviation from the communication flow without high-load computation or complex analysis procedures. Furthermore, because the sliding window is continuously updated according to the order of message reception, the set of valid identifiers also changes naturally in accordance with the communication patterns observed during actual vehicle operation.

[0133] The criteria for determining message identifiers received outside the sliding window as out-of-bounds messages are not arbitrarily set, but can be derived based on message flow data repeatedly observed in the actual vehicle internal network environment. For example, analyzing message logs collected from a test vehicle under normal driving conditions over a certain period reveals that message identifiers related to specific ECUs or functions appear repeatedly within a certain reception sequence. Based on these log analysis results, an empirical criterion can be established indicating that identifiers not appearing within the last N messages are highly likely to deviate from the normal communication flow.

[0134] The control unit can clearly distinguish between messages belonging to a normal communication flow and those that do not by maintaining only message identifiers within the sliding window as valid candidates according to these criteria. All information used in this process is limited to the actually received messages and their identifiers, and does not rely on separate abstract judgment elements or external input data. Therefore, a person skilled in the art can sufficiently reproduce the access blocking operation of this embodiment with only a basic implementation of receiving messages in the vehicle's internal network and comparing identifiers.

[0135] A control unit according to one embodiment of the present invention is configured to maintain only a continuous communication flow by removing the oldest message identifier and adding a new message identifier at each movement point of the sliding window. Here, the movement point of the sliding window refers to the point in time when a new message is received from the vehicle internal network and added to the sliding window, and occurs due to the message reception event itself, rather than external conditions such as the passage of time or the termination of a session.

[0136] The control unit manages the message identifiers constituting the sliding window in a sorted state according to the order of receipt. In this context, the oldest message identifier refers to the identifier received earliest among the message identifiers currently stored within the sliding window. The new message identifier refers to a message identifier extracted from a recently received message, and the control unit adds this identifier to the most recent position in the sliding window.

[0137] Specifically, when a new message is received while the number of message identifiers stored in the sliding window has reached the maximum number defined by the first window parameter, the control unit first removes the oldest message identifier from the sliding window. Subsequently, by adding the message identifiers included in the newly received message to the sliding window, the same number of the latest message identifiers are always maintained within the sliding window. This removal and addition process can be performed sequentially in response to a single message reception event, and a person skilled in the art can easily implement it using a queue, a circular buffer, or an index-based array structure.

[0138] As the sliding window moves in this manner, the set of message identifiers maintained within the sliding window reflects the continuous communication flow occurring within the actual vehicle internal network. In other words, in a normal communication environment, identical or similar message identifiers appear repeatedly while maintaining a consistent reception order; therefore, changes in the set of identifiers occur gradually during the movement of the sliding window. Conversely, if the communication flow is interrupted or an abnormal message is inserted, a discontinuity occurs between the set of identifiers within the sliding window and the received message identifiers.

[0139] The reason the control unit is configured to remove the oldest message identifier is to make judgments based solely on the recent continuous flow of communication, rather than on the entire history of past communications. This ensures that message identifiers received long ago do not influence subsequent judgment processes, allowing for the immediate reflection of communication patterns that change during actual driving. This structure adapts naturally even in vehicle environments where message reception frequency changes or specific functions are temporarily activated or deactivated.

[0140] The sliding window movement logic can be verified based on actual vehicle operation data. For example, normal communication logs between ECUs in a test vehicle can be collected, and the set of message identifiers maintained according to the movement of the sliding window can be identified by playing back the logs in the order they were received. In this process, it can be confirmed that while identifiers within the sliding window remain continuous under normal driving conditions, a clear discontinuity in the set of identifiers occurs when messages that are intentionally delayed or out of order are inserted.

[0141] In this way, the control unit is configured to maintain a continuous communication flow without complex calculations or external conditions by repeating a simple and clear operation of removing the oldest message identifier and adding a new message identifier at each movement point of the sliding window. Since the judgment criteria used are limited to the identifiers of the actually received messages and their reception order, a person skilled in the art can implement this embodiment without a separate reasoning process, and the implementation results can also be reproduced identically through repeated experiments.

[0142] A control unit according to one embodiment of the present invention sequentially performs counter-based verification based on first verification data, time-based verification based on second verification data, and sliding window-based verification based on second verification data as independent judgment steps, and immediately discards any message that fails to pass any of the judgment steps, and allows only messages that have passed all of the plurality of judgment steps to be used for control signals or state updates between ECUs, thereby preventing message replay attacks even in an internal vehicle network environment where the concept of a session does not exist and performing access control based on the continuity of the communication flow.

[0143] The independent judgment steps sequentially performed by the control unit refer to a judgment procedure in which the result of one verification is not used as an input or reference value for another verification, and each verification is performed individually according to different data and criteria. When a message is received, the control unit first performs a counter-based verification using the counter value included in the message as the first verification data, and configures the processing flow to perform the next step, a time-based verification, only if the result is determined to pass. Subsequently, it follows the sequence of performing a sliding window-based verification only if the time-based verification passes.

[0144] In the counter-based verification step, the control unit maintains the counter value of the message immediately received from the same ECU as an internally stored reference value and compares it with the counter value of the currently received message. The step is determined to have passed only if the current counter value increases by 1 or more compared to the reference value. Since this determination is performed solely through integer comparison operations, no separate complex calculations or external data are required. If the counter value decreases or remains the same, the message is immediately determined to have failed verification and is not passed to the subsequent step.

[0145] For messages that have passed counter-based verification, the control unit performs time-based verification. In this step, the control unit uses the time information included in the message as second verification data and calculates the time difference between the message creation time and the message reception time by comparing it with the server reference time or vehicle reference time maintained internally. The calculated time difference can be computed through a simple subtraction operation, for example, implemented as time_diff = recv_time - gen_time. The control unit determines that the message has passed time-based verification only if this time difference falls within an allowed time range. If it exceeds the allowed time range, it determines that the message has been delayed or retransmitted and immediately discards the message.

[0146] For messages that have passed time-based verification, the control unit performs sliding window-based verification. In this step, the control unit compares the set of message identifiers currently maintained within the sliding window with the message identifiers included in the received message. The message is determined to belong to a normal communication flow only if the corresponding message identifier is included among the valid candidates within the sliding window. Conversely, if the message contains a message identifier that does not exist within the sliding window, it is determined to be a message that has deviated from the communication flow, and the message is discarded.

[0147] The control unit is configured to sequentially perform these three verification steps and immediately discard any message that fails to pass any of them. Immediate discarding means that the message is not passed to subsequent processing steps, such as generating control signals between ECUs, updating state variables, or transmitting control commands; instead, it is removed from memory or treated solely as a log entry. This ensures that a single verification failure does not affect the judgment of other verification steps and prevents unnecessary consumption of computational resources.

[0148] Conversely, for messages that have passed counter-based verification, time-based verification, and sliding window-based verification, the control unit confirms the message as a valid message and allows it to be used for generating control signals or updating the state between ECUs. The control signals or state updates used at this time can be applied in the same manner as defined in the existing vehicle control logic, and this embodiment adopts a structure that determines only whether access is permitted in the preceding stage without modifying the content or structure of the said control logic.

[0149] This sequential and independent judgment structure can be verified based on message logs collected in an actual in-vehicle network environment. For example, when replaying message logs collected under normal driving conditions, most messages pass all three stages of verification; however, if past messages are arbitrarily inserted into the same log or their order is changed, it can be confirmed that they are immediately discarded during the counter-based or sliding window-based verification stages. Furthermore, repeated experiments confirm that if the creation time of a message is artificially altered, verification failure occurs during the time-based verification stage.

[0150] In this way, the control unit determines whether to allow access based solely on the data included in the actual message and the order of reception, without relying on session identifiers, login information, or state maintenance information. Therefore, even in an in-vehicle network environment where the concept of a session does not exist, a person skilled in the art can easily reproduce this embodiment using only basic implementations such as message reception, data comparison, and conditional branching, and the result of the determination can also be consistently verified through repeated experiments.

[0151] A control unit according to one embodiment of the present invention is configured to apply different verification strengths depending on the functional type of an ECU transmitting a message on a vehicle internal network. The control unit defines a message received from an ECU related to braking, steering, and power control as a first important message, and a message received from an ECU related to infotainment or status display as a second important message. The control unit performs counter-based verification, time-based verification, and sliding window-based verification for the first important message, and applies differential access control levels according to message importance by performing at least some of the verifications for the second important message.

[0152] A control unit according to one embodiment of the present invention is configured to apply different verification strengths depending on the functional type of an ECU transmitting a message on an internal vehicle network. Here, the functional type of the ECU refers to a classification distinguished based on the functional role that the ECU performs within the vehicle's control system, and the control unit distinguishes the importance of the message according to this functional role and applies different access control levels.

[0153] The control unit defines messages received from ECUs directly related to braking, steering, and power control as first critical messages. First critical messages are messages that affect the driving safety and immediate control operations of the vehicle, and they possess characteristics that can directly affect vehicle behavior if falsification, alteration, playback, or sequence errors occur in the messages. These first critical messages can be identified by correlating predefined ECU function type information with identification information of the message-sending ECU, and such correspondence information can be set based on the list of ECU functions or network configuration information defined during the vehicle design phase.

[0154] On the other hand, the control unit defines messages received from the ECU related to infotainment functions, user interface display, and status information transmission as second-critical messages. Second-critical messages are messages intended for the purpose of transmitting information that do not directly affect the driving control of the vehicle, and they have the characteristic that their impact on vehicle safety is relatively limited even if a certain level of delay or retransmission occurs. The control unit can also identify the function types of these ECUs based on ECU identification information and predefined function classification information.

[0155] The control unit is configured to perform counter-based verification, time-based verification, and sliding window-based verification for messages defined as first-critical messages. That is, a message received from an ECU related to braking, steering, or power control is accepted as a valid message only if it satisfies all of the following conditions: whether the counter value included in the message is monotonically increasing, the time difference between the message creation time and the reception time, and whether it contains an identifier within a sliding window reflecting the recent communication flow. Through such multi-stage verification, the possibility of replay attacks, delay attacks, or communication flow deviations is minimized for first-critical messages.

[0156] Conversely, the control unit applies differential access control levels to messages defined as second-critical messages, performing only at least some of the aforementioned verifications. For example, the control unit may be configured to perform only counter-based verification and sliding window-based verification for second-critical messages, omit time-based verification, or perform only counter-based verification. This configuration is intended to reduce message processing delays and decrease unnecessary computational burdens, and can be set considering that the functional importance of the message is relatively low.

[0157] Criteria for applying differential verification intensity based on message importance are not set arbitrarily, but can be derived based on message characteristics and functional impacts collected from the actual in-vehicle network environment. For example, the reception frequency, tolerance of delay, and the impact on vehicle operation upon retransmission of braking, steering, power control, and infotainment messages can be compared and analyzed while driving in a test vehicle. Through these analysis results, the sensitivity of specific message types to delays or retransmissions can be identified, and the number of verification steps to apply can be determined accordingly.

[0158] The control unit classifies messages into first and second important messages according to the function type of the ECU and applies different verification intensities to each message type, thereby ensuring both security and processing efficiency simultaneously without uniformly applying the same verification burden to the entire internal vehicle network. Since the judgment criteria used in this process are limited to the function type of the ECU, message classification information, and actual received message data, a person skilled in the art can easily implement this embodiment without separate abstract judgment and reproduce the same operational results through repeated vehicle testing.

[0159] A control unit according to one embodiment of the present invention is configured to classify a specific ECU as a temporary exclusion target in the list of normal communication ECUs when a message suspected of a replay attack is detected continuously for more than a preset number of times among messages received from the ECU, perform a verification procedure on subsequent messages received from the ECU classified as a temporary exclusion target, control that such messages are stored in a separate isolation area without being reflected in the vehicle's internal control logic, and determine whether communication of the ECU is restored based on the occurrence frequency, time interval, and counter fluctuation pattern of the messages stored in the isolation area.

[0160] A message suspected of a replay attack refers to a message determined not to be part of the normal communication flow because it failed to pass at least one of the counter-based verification, time-based verification, or sliding window-based verification in the preceding verification procedure. The control unit makes this determination based on whether such verification failures occur consecutively for messages having the same ECU identification information, and distinguishes between one-time errors and repetitive abnormal behavior.

[0161] Specifically, the control unit accumulates and manages the number of verification failure messages for each ECU, and classifies the ECU as a temporary exclusion target only when the number of consecutive verification failures reaches a preset threshold. This threshold can be set based on message logs collected in a normal driving environment. For example, if experimental measurements of the frequency of temporary verification failures caused by network delays or momentary bus collisions in a normal communication environment reveal that it is extremely rare for the same ECU to experience two or more consecutive verification failures, the possibility of a normal communication ECU being mistakenly blocked can be reduced by setting the threshold to three or more.

[0162] When the control unit classifies a specific ECU as a temporary exclusion target, that ECU is separated from the list of normal communication ECUs and managed independently. In this state, the control unit performs the same verification procedures as before on subsequent messages received from the temporarily excluded ECU, but controls the system so that the processing results are not reflected in the vehicle's internal control logic. In other words, the message is not used for generating control signals or updating the state, but is stored in a separately prepared isolation area. An isolation area refers to a memory or storage space separated from the normal control path, used solely for recording message content and for subsequent decision-making.

[0163] For messages stored in the isolation area, the control unit continuously monitors the occurrence frequency, time interval, and counter fluctuation pattern. Occurrence frequency refers to the number of messages entering the isolation area within a unit of time, and the time interval refers to the difference in reception times between consecutive messages. Additionally, the counter fluctuation pattern refers to a characteristic indicating whether the counter values ​​included in the isolated messages increase monotonically, fluctuate irregularly, or repeat.

[0164] Based on these observations, the control unit determines whether the communication status of the corresponding ECU has returned to a normal communication flow. For example, if the counter values ​​of messages stored in the isolation area increase continuously again, the time interval between message receptions is similar to the range observed in a normal ECU, and verification failures do not occur for a certain period, the control unit may determine that the ECU has emerged from a temporary error state. Conversely, if counter repetition, abnormal time intervals, or irregular message frequency persist even in the isolation state, the corresponding ECU is maintained in a temporary exclusion state.

[0165] Such criteria for determining communication recovery are not arbitrarily set but can be derived through repeated experiments in an actual vehicle internal network environment. By comparing the frequency, time intervals, and counter change patterns of messages stored in the isolation area when normal communication is restored after intentionally injecting replay attack messages or causing communication errors in a specific ECU in a test vehicle, trends that distinguish between the normal recovery state and the abnormal state can be identified. Based on this experimental data, the control unit can establish criteria for determining whether communication has been restored.

[0166] In this way, the control unit is configured to evaluate the communication status through stages of temporary exclusion and isolated observation, rather than immediately and permanently blocking an ECU where messages suspected of replay attacks repeatedly occur. This allows for the prevention of excessive blocking of normal ECUs due to temporary errors while maintaining the stability of the vehicle's internal network. Since the above judgment process is based solely on the actual received message data and its temporal and sequential characteristics, a person skilled in the art can implement this embodiment without any separate abstract assumptions and obtain results that are repeatedly reproducible under the same experimental conditions.

[0167] A control unit according to one embodiment of the present invention identifies vehicle operation status information including a starting state, a driving state, or a stopping state of a vehicle internal network, and variably sets at least one of the size of the sliding window, an allowable time range, or an allowable counter increase width according to the vehicle operation status information.

[0168] Vehicle operation status information is status information indicating whether the vehicle is currently in a state where the engine is started, is actually driving, or is in a stationary state, and can be identified by a signal value shared through the vehicle's internal network or a status flag generated by the ECU.

[0169] The control unit identifies vehicle operation status information using operation status-related messages received periodically or on an event basis on the vehicle internal network. For example, the starting status can be identified through at least one of a start switch signal, a status signal of a power management ECU, or an active status signal of a powertrain ECU; the driving status can be identified based on whether the vehicle speed value is greater than 0, a transmission status signal, or a wheel rotation signal; and the stopping status can be identified through conditions where the vehicle speed is maintained at 0 and the braking state is sustained. Since these signals are common control signals already exchanged on the vehicle internal network, they can be easily utilized by a skilled technician without the need for separate additional sensors.

[0170] The control unit can variably set the size of the sliding window according to identified vehicle operation status information. The size of the sliding window refers to the number of message identifiers maintained to determine continuous communication flow. For example, when the vehicle is stationary, the frequency of message occurrence is relatively low and changes in communication flow are gradual; therefore, the size of the sliding window can be set relatively large to enable gradual judgment that includes past messages. Conversely, when the vehicle is in motion, the frequency of message occurrence is high and the impact of communication delays or attacks can be immediately reflected in vehicle control; therefore, the size of the sliding window can be reduced to allow for stricter judgment based only on recent message flow.

[0171] In addition, the control unit can variably set the allowable time range based on vehicle operation status information. The allowable time range refers to the range in which the time difference between the time of message generation and the time of message reception is recognized as normal. For example, immediately after starting the engine or while stationary, message delivery times may be relatively irregular due to network initialization or ECU startup delays, so the allowable time range can be set relatively wide. On the other hand, since the network operates stably during driving, the allowable time range can be narrowed to more strictly exclude messages susceptible to replay attacks caused by delays or retransmissions.

[0172] The control unit can also variably set the allowable counter increment range based on vehicle operation status information. The allowable counter increment range refers to the range of increase in which the counter value between continuously received messages is recognized as normal. For example, when the vehicle is stationary or immediately after starting, the counter value may temporarily increase significantly during the initial synchronization process between ECUs, so the allowable range can be set relatively large. On the other hand, in a driving state, since it can be confirmed through repeated experiments that the counter value maintains a constant increment pattern in the normal communication flow, the allowable range can be reduced to enable more sensitive detection of abnormal counter jumps.

[0173] Such variable setting criteria for each vehicle operating state can be derived through actual vehicle operation tests. For example, using a test vehicle, the message reception interval, counter increment pattern, and time delay distribution can be repeatedly measured in the ignition, stationary, and driving states, respectively. The measurement results may confirm that in the driving state, the time dispersion between messages is small and the counter increment pattern remains stable, whereas in the ignition or stationary states, the fluctuation range is relatively large. Based on this actual measurement data, the control unit can set the sliding window size, allowable time range, and allowable counter increment range suitable for each operating state.

[0174] In this way, the control unit identifies vehicle operation status information and variably adjusts the parameters used for communication verification according to the status, thereby ensuring both the continuity and security of the communication flow without uniformly applying the same standards to all situations. Since the above operation is performed using only operation status signals already exchanged in the actual vehicle internal network and received message data, a person skilled in the art can implement this embodiment without additional reasoning or complex algorithms, and can reproduce the same operation results through repeated experiments under the same operating conditions.

[0175] A control unit according to one embodiment of the present invention is configured to strengthen communication verification conditions by reducing the size of the sliding window or decreasing the allowable time range when the vehicle is in a driving state compared to when it is in a stationary state, thereby suppressing the possibility of replay attacks in stages according to the vehicle's operating conditions.

[0176] The stationary state and the driving state are distinguished by vehicle operation status information, and the control unit applies different parameters used for communication verification based on the already identified operation status.

[0177] Reducing the size of the sliding window by the control unit means decreasing the number of message identifiers maintained to determine a continuous communication flow. For example, when the vehicle is stationary, the sliding window size can be set relatively large to determine the communication flow based on a large number of recently received message identifiers. Conversely, when the vehicle switches to a driving state, the control unit reduces the size of the sliding window to determine the continuity of the communication flow only within a shorter message interval. By reducing the size of the sliding window in this way, gradual judgments based on past messages are restricted, and stricter access control is implemented based solely on recently received messages.

[0178] In addition, the control unit is configured to reduce the allowable time range when the vehicle is in a driving state. The allowable time range refers to the range in which the time difference between the time of message generation and the time of message reception is recognized as normal communication. In a stationary state, message delivery times may be relatively irregular due to ECU initialization, network reconfiguration, or temporary communication delays, so the allowable time range can be set relatively wide. On the other hand, in a driving state, since it can be confirmed through repeated experiments that the vehicle's internal network operates stably and the message cycle remains constant, the control unit reduces the allowable time range to more sensitively block messages susceptible to replay attacks caused by time delays or retransmissions.

[0179] Such a method for strengthening verification conditions can be derived based on actual vehicle operation data. For example, message reception intervals and time delay distributions can be repeatedly measured using a test vehicle in both stationary and driving states. The measurement results may reveal a tendency for the time deviation between messages to be small and concentrated within a certain range in the driving state, whereas the deviation tends to be relatively larger in the stationary state. Based on these actual measurement results, the control unit can set the sliding window size and allowable time range to be applied in the driving state more strictly than in the stationary state.

[0180] The control unit progressively strengthens communication verification conditions according to vehicle operating conditions by applying either a reduction in the size of the sliding window or a decrease in the allowable time range, or both. In other words, as the vehicle transitions from a stationary state to a driving state, the communication verification criteria become progressively stricter, thereby gradually suppressing the possibility of replay or delay attacks affecting vehicle control. Since this process is achieved through parameter adjustments based on changes in operating conditions rather than the blanket application of specific thresholds, access control that reflects the actual operating context of the vehicle is possible.

[0181] As such, the control unit is configured to dynamically strengthen communication verification conditions according to vehicle operating conditions, and the judgment criteria and adjustment parameters used are based on message data and driving status information collected from the actual vehicle internal network. Therefore, a person skilled in the art can easily implement this embodiment with only simple implementations, such as basic signal identification to distinguish between a stationary state and a driving state, and adjusting the sliding window size and allowable time range, and can reproduce the same suppression effect through repeated experiments under the same operating conditions.

[0182] A control unit according to one embodiment of the present invention implements an access control method dedicated to an in-vehicle network that is structurally distinct from the session-centric access control structure of a TCP / IP-based IT network by performing access control based solely on a counter value, time information, and reception order included in a message, without using user login, session identifier generation, or session maintenance information at all.

[0183] User login information refers to information used to identify a communication subject through procedures such as user account authentication, ID / password verification, or token issuance, and session identifier generation information refers to a session ID or equivalent identification information assigned to logically maintain a communication connection in a TCP / IP-based network. The control unit does not generate or store such information, nor does it refer to it during the communication flow determination process.

[0184] Instead, the control unit determines the continuity of the communication flow using only the counter value, time information, and reception order included in each message. The counter value is an integer value that is incremented by the ECU transmitting the message at each message generation time, representing the order between messages continuously received from the same ECU. The control unit can determine whether the message has been delivered in the normal order by checking whether the counter value included in the received message changes in an increasing direction compared to the counter value of the same ECU received immediately before. In this case, the increment range of the counter value can be set to increase by 1 or to cycle within a certain range depending on the ECU implementation method, and the control unit can be implemented to recognize only the increment pattern within that range as normal communication.

[0185] Time information is a time value assigned by the ECU at the time of message creation or transmission, and may include absolute or relative time. The control unit calculates the difference between the time of message reception and the time information included in the message to determine whether the difference falls within an acceptable range. In this process, the control unit does not operate a separate session timer or connection-keep timer, but performs the judgment based solely on the time information included in the message. This allows it to determine whether the message itself was received within the normal flow of time, rather than whether the communication connection is being maintained.

[0186] The reception order refers to the order in which the control unit actually receives messages. The control unit determines the relative order for the same ECU or the same message type by sequentially recording messages at each reception point. For example, if messages containing the same counter value and time information are received repeatedly and discontinuously, the control unit can identify them as discontinuous messages in terms of reception order. This determination enables access control to be performed based solely on the continuity of the message flow itself, without maintaining the session state.

[0187] In this manner, the control unit determines the continuity of the communication flow by combining message-unit counter values, time information, and the reception order. This determination structure is distinct from the session-centric access control structure used in TCP / IP-based IT networks. In TCP / IP-based networks, the communication state is managed through procedures such as connection establishment, session maintenance, and session termination, and access rights are determined based on session identifiers. On the other hand, the control unit of this embodiment performs access control based solely on the continuity of the message itself, without presupposing connection or session concepts, in accordance with the characteristics of the in-vehicle network.

[0188] This can be derived based on communication characteristics actually observed within the vehicle's internal network. For example, if messages between ECUs are collected and analyzed within the internal network of a test vehicle, it can be repeatedly confirmed that under normal driving conditions, the counter values ​​and reception order of messages transmitted from a specific ECU maintain a consistent pattern, and the time deviation also remains within a limited range. Based on this actual data, the control unit can be implemented on the premise that the continuity of the message flow can be sufficiently determined without using session information.

[0189] Consequently, the control unit can perform access control using only the minimum information contained in the message, without additional management structures such as session creation and maintenance. A person skilled in the art can implement this embodiment with simple logic that stores and compares a counter value, time information, and reception order upon message reception, and can easily implement an access control method dedicated to the vehicle's internal network without adding a separate network session management module.

[0190] A control unit according to one embodiment of the present invention is configured to analyze the bit distribution characteristics within the data field of a message received on an internal vehicle network and verify whether it matches a predefined bit transition pattern for each message type.

[0191] A data field may consist of a fixed-length or variable-length bit sequence, such as the data area of ​​a CAN frame, for example, and the control unit stores the bit sequence in the order of reception or uses it immediately for analysis. Bit distribution characteristics refer to statistical and structural characteristics such as the frequency with which each bit position within the data field is set to a logical value of 0 or 1, the duration of consecutive identical bits, and whether transitions occur between adjacent bits, which form a unique pattern that is repeatedly observed for a specific message type.

[0192] The control unit stores predefined bit transition patterns for each message type and verifies whether there is a match between the bit distribution characteristics observed in the data field of a received message and the said bit transition patterns. Here, message types can be distinguished according to predefined functional classification criteria on a message identifier, a transmitting ECU, or a network, and for each message type, the combination of bit positions where changes occur and bit positions where changes do not occur within the data field is different. By tracking changes in bit values ​​in multiple consecutively received messages for each bit position in the data field, the control unit identifies whether the corresponding bit remains fixed or transitions only under specific conditions, and defines this identification result as a bit transition characteristic.

[0193] A bit transition pattern can be expressed, for example, as the average period during which a transition from 0 to 1 occurs at a specific bit position, the transition rate between consecutive messages, or the length of a bit interval where no transition occurs, and the control unit determines whether a received message follows the normal data generation behavior of the corresponding message type based on these values. To this end, the control unit calculates bit distribution characteristics in the same manner for message data collected from the actual vehicle internal network during normal operation and registers the results as reference bit transition patterns for each message type. In this process, a reference pattern is formed by collecting a sufficient number of messages for the same message type and confirming that the transition frequency and retention characteristics at a specific bit position are repeatedly reproduced.

[0194] The control unit applies the same bit distribution analysis procedure to the data field of the subsequently received message and compares whether the calculated bit transition characteristics match the reference bit transition pattern within an acceptable range. For example, even though a specific bit position in the reference pattern is defined to always maintain the same value throughout a continuous message, if that bit position transitions frequently in the received message, the control unit can identify this as a data field variation that differs from normal message generation logic. Conversely, if a bit position where periodic transitions occur in the reference pattern does not change at all, it can also be determined as an abnormal data field characteristic.

[0195] Since such analysis of bit distribution characteristics is performed based solely on the physical bit configuration of the data field itself and its change patterns, without relying on the interpretation of message semantics or higher-level control logic, a person of ordinary technical expertise can implement it using only bit-level access. In actual implementation, the data field is stored in the form of a byte array or a bit array, and the presence of a bit transition can be determined by comparing the value change between the previous message and the current message for each bit index; the bit distribution characteristics can then be calculated by accumulating these comparison results. Since this procedure is performed based on bit transition patterns defined by data repeatedly verified in a normal communication environment during vehicle operation, it is implemented as a verification method based on the observation results of actual message data rather than the setting of arbitrary criteria.

[0196] A control unit according to one embodiment of the present invention calculates a bit pattern feature value for a plurality of messages having the same message identifier, including the number of transitions of a continuous bit sequence within a data field, whether a fixed bit position is maintained repeatedly, or the bit inversion frequency; and if the calculated bit pattern feature value deviates from a normal pattern range stored corresponding to the message type, the control unit identifies the message as an abnormally generated message and blocks its transmission to the vehicle's internal control logic.

[0197] The data field consists of a bit sequence of a fixed length according to the vehicle's internal network specifications, and the control unit tracks changes in bit values ​​between consecutively received messages based on the same bit index for each message. Through this, the control unit calculates the number of transitions in the consecutive bit sequence within the data field, whether a specific bit position repeatedly maintains the same value, and the frequency of value inversion at each bit position.

[0198] The number of transitions in a sequence of bits refers to the number of points within a data field where adjacent bits change from 0 to 1 or from 1 to 0. The control unit sequentially compares a single message data field from the left bit to the right bit and counts a transition when the values ​​between adjacent bits differ. Since this number of transitions appears repeatedly within a certain range depending on the message type, the control unit collects multiple messages for the same message identifier to determine the distribution of the average number of transitions and stores this as reference data.

[0199] The repeated maintenance of a fixed bit position is defined as an indicator representing whether the value of a specific bit index remains unchanged and is continuously maintained across consecutive messages with the same message identifier. The control unit can determine whether the corresponding bit position is a normally fixed bit by accumulating the number of times the same value is maintained in consecutively received messages for each bit index and calculating the maintenance ratio relative to the total number of messages. This fixed bit characteristic is stored based on results repeatedly observed through message data collected under normal conditions during actual vehicle operation.

[0200] The bit inversion frequency refers to the number of times the value changes between two consecutive messages at the same bit position. The control unit calculates the inversion frequency by accumulating the number of inversions for each bit index and dividing the result by the number of messages. This inversion frequency can be used as a criterion to distinguish between signal bits that are periodically updated and status bits that are always maintained in the message generation logic. For the same message identifier, the control unit stores the distribution range of the inversion frequency by bit position from data collected during normal operation.

[0201] The control unit generates a bit pattern feature value for a single message, including the number of consecutive bit sequence transitions, the fixed bit position retention rate, and the bit inversion frequency calculated as described above, and compares it with the normal pattern range stored corresponding to the message type. The normal pattern range is set based on the results of calculating feature values ​​in the same manner for messages collected while maintaining a normal communication state for a certain period of time or longer in the actual vehicle internal network, and is defined in a form that includes an acceptable upper and lower limit range rather than a single specific value.

[0202] As a result of the comparison, if any of the bit pattern feature values ​​of the received message deviate from the normal pattern range, the control unit determines that the message is an abnormally generated message that was not created by normal ECU generation logic. In this case, the control unit does not transmit the message to the vehicle's internal control logic but immediately blocks it so that it is not used for reflecting control signals or updating the state. Since this determination and blocking process is performed based solely on the bit configuration of the data field and its change patterns, regardless of the interpretation of the message content's meaning or the state of the higher-level application, a person of ordinary skill can easily implement it using only bit-level comparison and counting logic.

[0203] The calculation of such bit pattern feature values ​​and the setting of normal pattern ranges are based on message data repeatedly collected from the actual vehicle internal network, and are stored after confirming that the observed bit distribution characteristics for each message type are stably reproduced. Therefore, the above verification process is not based on arbitrarily defined criteria, but is performed based on characteristics derived through data collection and iterative verification in an actual operating environment, and the control unit can effectively identify and block abnormally generated messages through this data-based feature comparison.

[0204] A control unit according to one embodiment of the present invention collects communication behavior parameters including the average transmission period, transmission interval variance, or bus occupancy ratio of messages having the same message identifier on a vehicle internal network, and the control unit compares the communication behavior parameters with reference communication profiles stored by ECU and message type, and if a sudden shortening of the transmission period, the repeated occurrence of non-periodic transmission intervals, or an increase in the bus occupancy ratio of a specific ECU is detected, the control unit identifies the message as a communication abnormality message that is unlikely to occur in a normal operating state and restricts its reflection into the vehicle internal control logic.

[0205] A control unit according to one embodiment of the present invention receives messages having the same message identifier in chronological order on an internal vehicle network and calculates a transmission period and a transmission interval based on the time of reception of each message. Here, the average transmission period is calculated by accumulating the difference in reception time between consecutive messages having the same message identifier and dividing by the number of messages, and the transmission interval variance is a value indicating how much each transmission interval deviates from the average transmission period, calculated by accumulating the difference between consecutive transmission intervals and the average transmission period. Such calculation of the transmission period and transmission interval can be performed by recording the time of message reception as a timestamp, so a person skilled in the art can easily implement it by simply calculating the time difference.

[0206] The bus occupancy rate refers to the proportion of the vehicle's internal network bus used by a specific ECU over a set time interval. The control unit calculates this rate by dividing the number of messages or data lengths received from the ECU by a reference time interval. For example, the bus occupancy rate can be defined by calculating the proportion of messages transmitted by a specific ECU out of the total messages received over a set period, or by accumulating the proportion of the total transmission time occupied by the ECU. This approach is repeatedly applicable in actual vehicle internal networks and can be implemented without the need for complex separate modeling.

[0207] The control unit defines the average transmission period, transmission interval variance, and bus occupancy ratio calculated as described above as communication behavior parameters, and stores them separately by ECU and message type. The reference communication profile stored at this time is configured to include a range of values ​​obtained by repeatedly performing the same calculation process based on message data collected for a certain period of time or longer while the vehicle is in a normal operating state. In other words, rather than a specific single value, the range of transmission period variation observed during normal operation, the allowable range of transmission interval variance, and the general distribution of bus occupancy ratios by ECU are stored as the reference communication profile.

[0208] Subsequently, the control unit compares the communication behavior parameters calculated for the newly received message with the reference communication profile corresponding to the message identifier and the ECU. As a result of the comparison, if the average transmission period is drastically shortened compared to the reference range, it is determined that the message may not have been generated by normal periodic control logic. Furthermore, if the transmission interval variance repeatedly exceeds the reference range and non-periodic transmission intervals continuously occur, it is identified as a communication anomaly that is unlikely to occur under normal operating conditions. Moreover, if the bus occupancy rate of a specific ECU increases significantly compared to the reference communication profile, it can be determined that the ECU is transmitting an abnormally excessive number of messages.

[0209] If any of the above comparison processes deviate from the reference communication profile, the control unit identifies the corresponding message as a communication anomaly message unlikely to occur under normal operating conditions and restricts its transmission to the vehicle's internal control logic. This restriction can be implemented by completely discarding the message or by processing it separately so that it is not reflected in control signals or state updates. Since this judgment and restriction process can be implemented using only time information and the number of messages collected from the actual vehicle internal network, a person of ordinary skill can implement it without additional external data or complex learning models.

[0210] As such, the process of collecting communication behavior parameters and establishing and comparing reference communication profiles is configured based on communication characteristics repeatedly observed during actual vehicle operation, and a stable reference range is derived through data collection and verification in a normal operating environment. Therefore, the aforementioned communication anomaly message identification process is implemented in a structure that utilizes criteria naturally derived from repeated observation results based on actual data, rather than arbitrarily set conditions. Explanation of the symbols

[0212] 100: User terminal 110: User Input Section 120: Display section 200: Server 210: Communications Department 220: Storage section 230: Control unit

Claims

Claim 1 A vehicle internal network access control system comprises a user terminal including a display unit and a user input unit; and a server connected to the user terminal via a wired or wireless network, wherein the server comprises a communication unit; a storage unit; and a control unit.The control unit is configured to process messages received from a plurality of electronic control units (ECUs) connected to an internal vehicle network on a message basis rather than a session basis, and the control unit identifies a communication flow based on the transmitting ECU identification information, message identifier, message payload, and message reception time included in each message, and determines whether to allow access to the communication flow based on the continuity and temporal validity of the message itself, regardless of the existence of user authentication or a login session, and the control unit defines a counter value attached to a message received from each ECU as first verification data, sets a counter value included in a previously received message from the same ECU as a reference value, and identifies whether the first verification data has monotonically increased by comparing whether the counter value of the currently received message has increased by 1 or more than the reference value, and the control unit controls access by determining the message as a replay message and blocking access if the counter value decreases or is received repeatedly with the same value, and the control unit is configured to restrict message reception by the corresponding ECU by identifying it as an abnormal communication flow if the counter value increases continuously but exceeds a predefined maximum increase range, and the control unit each A vehicle internal network access control system characterized by defining time information included in a message as second verification data, and the control unit calculating the time difference between the message reception time and the message creation time by comparing the second verification data with the server reference time or the vehicle reference time, and the control unit identifying the message as a valid message only if the time difference falls within a preset allowable time range, and if it exceeds the allowable time range, determining the message as a message capable of replay attacks via delay or retransmission and controlling access to block access. Claim 2 delete Claim 3 delete Claim 4 delete Claim 5 A vehicle internal network access control system characterized in that, in claim 1, the control unit creates a sliding window that stores a plurality of recently received messages based on the order of message reception, defines the size of the sliding window by a first window parameter set based on the number of messages, the control unit maintains only message identifiers included within the sliding window as valid candidates, and controls the blocking of access by identifying messages containing message identifiers received outside the sliding window as messages that have deviated from the communication flow, and the control unit is configured to maintain only a continuous communication flow by removing the oldest message identifier and adding a new message identifier at each point of movement of the sliding window. Claim 6 A vehicle internal network access control system characterized in that, in claim 5, the control unit sequentially performs counter-based verification based on first verification data, time-based verification based on second verification data, and sliding window-based verification, each as independent judgment steps, and the control unit immediately discards any message that fails to pass any of the judgment steps, and the control unit allows only messages that have passed all of the plurality of judgment steps to be used for control signals or state updates between ECUs, thereby preventing message replay attacks and performing access control based on the continuity of communication flow even in a vehicle internal network environment where the concept of a session does not exist. Claim 7 A vehicle internal network access control system according to claim 6, wherein the control unit is configured to apply different verification strengths depending on the function type of the ECU transmitting messages on the vehicle internal network, the control unit defines messages received from an ECU related to braking, steering, and power control as first important messages, and messages received from an ECU related to infotainment or status display as second important messages, and the control unit performs counter-based verification, time-based verification, and sliding window-based verification for the first important messages, and performs only at least some of the verifications for the second important messages, thereby applying differential access control levels according to message importance. Claim 8 A vehicle internal network access control system according to claim 7, wherein the control unit classifies the ECU as a temporary exclusion target in the list of normal communication ECUs when a message suspected of a replay attack is detected continuously for more than a preset number of times among messages received from a specific ECU, performs a verification procedure on subsequent messages received from the ECU classified as a temporary exclusion target, but controls them to be stored in a separate isolation area without reflecting them in the vehicle internal control logic, and the control unit is configured to determine whether communication of the ECU is restored based on the occurrence frequency, time interval, and counter fluctuation pattern of the message stored in the isolation area. Claim 9 A vehicle internal network access control system according to claim 8, wherein the control unit identifies vehicle operation status information including the starting state, driving state, or stopping state of the vehicle internal network, and variably sets at least one of the size of the sliding window, the allowable time range, or the allowable width of the counter increase according to the vehicle operation status information, and the control unit strengthens communication verification conditions by reducing the size of the sliding window or decreasing the allowable time range when the vehicle is in a driving state compared to when the vehicle is in a stopping state, and thereby is configured to suppress the possibility of a replay attack in stages according to the vehicle operation situation. Claim 10 A vehicle in-vehicle network access control system characterized in that, in claim 9, the control unit performs access control by determining the continuity of the communication flow based solely on the counter value, time information, and reception order included in the message, without using user login, session identifier generation, or session maintenance information at all, thereby implementing an access control method dedicated to a vehicle in-vehicle network that is structurally distinct from the session-centric access control structure of a TCP / IP-based IT network.

Images