Patent Description:
A plurality of devices may access data over a network. For example, a smartphone may transmit or receive data with a server on the Internet. The network may include a private network such as the intranet as well as a public network such as the Internet.

A technology for restricting access to the network based on transmission control protocol (TCP)/Internet protocol (IP) is being applied to control indiscriminate access to a network. For example, a network access controller (NAC) allows an authorized terminal to access a network by receiving the authorized IP address and blocks an unauthorized terminal by using address resolution protocol spoofing (ARP spoofing) when the unauthorized terminal uses an unauthorized IP address. A firewall refers to a method of determining whether to allow transmission of a data packet, based on source IP, destination IP, and port information, which are included in IP header information, and a policy. A virtual private network (VPN) refers to a method that guarantees the integrity and confidentiality of data packets by using a tunnel, to which encryption is applied, on the TCP/IP protocol. Nowadays, the number of companies using two or more security technologies among NAC, a firewall, and VPN is increasing. Besides the security technologies, a key-in method (e.g., entering an ID and a password) or a multi-factor authentication method is used to authenticate a user's identity during the first network access.

US Patent <CIT> discloses a system allowing to protect network devices from an unauthorized access on basis of a client. International patent application <CIT> discloses a tunnel detection method.

ARP spoofing may be a load on a network. Recently, a technology for bypassing the ARP spoofing has been developed. The firewall may be used to control the flow of data packets, and thus may not be directly involved in a process of generating a connection between two nodes. VPN is vulnerable to managing the flow of data packets after a tunnel is generated. Furthermore, advanced persistent threat (APT) uses a method of hiding malware capable of taking control of a terminal by executing a key logger in the terminal. A method of authenticating a user's identity is not performed after the first network access. Accordingly, credential stuffing using an ID and a password, which are obtained by using a key logger during VPN or NAC-based access, may occur frequently. Besides, the technologies are based on TCP/IP, and thus may be vulnerable to security on another layer (e.g., an application layer) among open system interconnection (OSI) layers.

Various embodiments disclosed in the specification provide a system for solving the above-described problems in a network environment, and a method therefor.

According to an embodiment disclosed in the specification, a terminal is defined according to claim <NUM>.

According to an embodiment disclosed in the specification, a is defined according to claim <NUM>.

According to an embodiment disclosed in the specification, a gateway is defined according to claim <NUM>.

According to embodiments disclosed in the specification, a terminal may block data packet transmission of an unauthorized network, terminal, user, or application.

Furthermore, embodiments disclosed in the specification may solve the problem of setting and retrieving a policy and may prevent bypass attacks as compared to a wide range of IP address-based network security technologies such as NAC.

Moreover, embodiments disclosed in the specification may block a man-in-the-middle (MITM) attack in a zero trust network environment, and thus tunnel-based access control may be performed as compared to VPN that provides only section protection.

Moreover, embodiments disclosed in the specification may block an access trial of a detour data packet to a destination network when enhanced authentication is not performed at the time of network access, by blocking the network access at the stage of a terminal and gateway.

Moreover, an access control application according to embodiments disclosed in the specification may fundamentally block credential stuffing that malware, which is hidden in a terminal and is being executed, attempts to access a target network by using authentication information obtained in advance.

Moreover, an access control application according to embodiments disclosed in the specification may perform enhanced authentication incapable of being collected by a key logger while accessing a network depending on a controller's instructions, and may allow the network access only through valid authentication, thereby providing a secure security element.

Besides, a variety of effects directly or indirectly understood through the specification may be provided.

With regard to description of drawings, the same or similar components will be marked by the same or similar reference signs.

Hereinafter, various embodiments of the present disclosure will be described with reference to accompanying drawings.

In this specification, the singular form of the noun corresponding to an item may include one or more of items, unless interpreted otherwise in context. In the present disclosure, the expressions "A or B", "at least one of A and B", "at least one of A or B", "A, B, or C", "at least one of A, B, and C", and "at least one of A, B, or C" may include any and all combinations of one or more of the associated listed items. The terms, such as "first" or "second" may be used to simply distinguish the corresponding component from the other component, but do not limit the corresponding components in other aspects (e.g., importance or order). When a component (e.g., a first component) is referred to as being "coupled with/to" or "connected to" another component (e.g., a second component) with or without the term of "operatively" or "communicatively", it may mean that a component is connectable to the other component, directly (e.g., by wire), wirelessly, or through the third component.

Each component (e.g., a module or a program) of components described in this specification may include a single entity or a plurality of entities. According to various embodiments, one or more components of the corresponding components or operations may be omitted, or one or more other components or operations may be added. Alternatively or additionally, a plurality of components (e.g., a module or a program) may be integrated into one component. In this case, the integrated component may perform one or more functions of each component of the plurality of components in the manner same as or similar to being performed by the corresponding component of the plurality of components prior to the integration. According to various embodiments, operations executed by modules, programs, or other components may be executed by a successive method, a parallel method, a repeated method, or a heuristic method. Alternatively, at least one or more of the operations may be executed in another order or may be omitted, or one or more operations may be added.

The term "module" used herein may include a unit, which is implemented with hardware, software, or firmware, and may be interchangeably used with the terms "logic", "logical block", "part", or "circuit". The "module" may be a minimum unit of an integrated part or may be a minimum unit of the part for performing one or more functions or a part thereof. For example, according to an embodiment, the module may be implemented in the form of an application-specific integrated circuit (ASIC).

Various embodiments of the present disclosure may be implemented with software (e.g., a program or an application) including one or more instructions stored in a storage medium (e.g., a memory) readable by a machine. For example, the processor of a machine may call at least one instruction of the stored one or more instructions from a storage medium and then may execute the at least one instruction. This enables the machine to operate to perform at least one function depending on the called at least one instruction. Herein, 'non-transitory' just means that the storage medium is a tangible device and does not include a signal (e.g., electromagnetic waves), and this term does not distinguish between the case where data is semipermanently stored in the storage medium and the case where the data is stored temporarily.

A method according to various embodiments disclosed in the specification may be provided to be included in a computer program product. The computer program product may be traded between a seller and a buyer as a product. The computer program product may be distributed in the form of a machine-readable storage medium (e.g., compact disc read only memory (CD-ROM)) or may be distributed (e.g., downloaded or uploaded), through an application store (e.g., PlayStore™), directly between two user devices (e.g., smartphones), or online. In the case of on-line distribution, at least part of the computer program product may be at least temporarily stored in the machine-readable storage medium such as the memory of a manufacturer's server, an application store's server, or a relay server or may be generated temporarily.

<FIG> illustrates an environment including a plurality of networks.

Referring to <FIG>, a first network <NUM> and a second network <NUM> may be different networks from each other. For example, the first network <NUM> may be a public network such as Internet, and the second network <NUM> may be a private network such as an intranet or VPN.

The first network <NUM> may include a terminal <NUM>. In various embodiments described with reference to <FIG>, 'terminal(s)' may be various types of devices capable of performing data communication. For example, the terminal <NUM> may include a portable device such as a smartphone or tablet, a computer device such as a desktop or laptop, a multimedia device, a medical device, a camera, a wearable device, a virtual reality (VR) device, or a home appliance device, but is not limited to the devices described above. The terminal <NUM> may also be referred to as an 'electronic device' or a 'node'.

The terminal <NUM> may attempt to access the second network <NUM> and may transmit data to servers 102a and 102b included in the second network <NUM>. The terminal <NUM> may transmit data to the servers 102a and 102b through a gateway <NUM> and a tunnel <NUM>. <FIG> illustrates an example in which the second network <NUM> includes only a server. However, according to various embodiments, the second network <NUM> may further include an electronic device such as the terminal <NUM> or a terminal.

When it is approved that the terminal <NUM> accesses the first network <NUM>, the terminal <NUM> may communicate with all servers included in the first network <NUM>, and thus the terminal <NUM> may be exposed from attacks by malicious programs. For example, in addition to trusted and/or secure applications such as an Internet web browser 110a and a business application 110b, the terminal <NUM> may receive data of untrusted or unsecured applications such as a malicious code 110c and an infected business application 110d.

The terminal <NUM> infected by a malicious program may attempt to access the second network <NUM> and/or to transmit data. When the second network <NUM> is formed based on IP, such as VPN, it may be difficult for the second network <NUM> to individually monitor a plurality of devices included in the second network <NUM>. The second network <NUM> may be vulnerable to security for an application layer or a transport layer in an OSI layer. Also, when the terminal <NUM> includes a malicious application after a tunnel has already been generated, the data of the malicious application may be delivered to another electronic device in the second network <NUM>.

<FIG> illustrates architecture in a network environment, according to various embodiments.

Referring to <FIG>, the number of a terminal <NUM>, a gateway <NUM>, and a destination network <NUM> is not limited to the number shown in <FIG>. For example, the terminal <NUM> may transmit data to a plurality of destination networks through a plurality of gateways, and a controller <NUM> may manage a plurality of terminals and a gateway. The terminal <NUM> may perform a function identical or similar to that of the terminal <NUM> shown in <FIG>; the gateway <NUM> may perform a function identical or similar to that of the gateway <NUM> shown in <FIG>; and, the destination network <NUM> may have a structure identical or similar to that of the first network <NUM> or the second network <NUM> of <FIG>.

For example, the controller <NUM> may be a server (or a cloud server). The controller <NUM> may guarantee reliable data transmission in a network environment by managing data transmission between the terminal <NUM>, the gateway <NUM>, and another network (e.g., the destination network <NUM>). For example, the controller <NUM> may manage access of the terminal <NUM> to the destination network <NUM> through policy information or blacklist information, may relay the generation of an authorized tunnel <NUM> between the terminal <NUM> and the gateway <NUM>, or may remove the tunnel <NUM> depending on the security event collected from the terminal <NUM> or the gateway <NUM>. The terminal <NUM> may communicate with the destination network <NUM> only through the tunnel <NUM> authorized by the controller <NUM>. When the authorized tunnel <NUM> is not present, the terminal <NUM> may be blocked from accessing the destination network <NUM>. According to an embodiment, the controller <NUM> may transmit or receive control data packets to or from the terminal <NUM> to perform various operations (e.g., registration, approval, authentication, update, and termination) associated with network access of the terminal <NUM>. A flow (e.g., <NUM>) through which a control data packet is transmitted may be referred to as a control flow.

The gateway <NUM> may be positioned on the boundary of the network, to which the terminal <NUM> belongs, or on the boundary of the destination network <NUM>. The plurality of gateways <NUM> may be present. The gateway <NUM> may forward only a data packet, which is received through the authorized tunnel <NUM>, from among data packets received from the terminal <NUM> to the destination network <NUM>. A flow (e.g., <NUM>) through which a data packet is transmitted between the terminal <NUM> and the gateway <NUM> or between the gateway <NUM> and the destination network <NUM> may be referred to as a "data flow". According to an embodiment, the gateway <NUM> may be connected to the controller <NUM> based on a cloud. The gateway <NUM> may generate the tunnel <NUM>, which is authorized and which is connected to the terminal <NUM>, under the control of the controller <NUM>. According to an embodiment, even though a data packet transmitted from terminal <NUM> is received through the authorized tunnel, the gateway <NUM> may control the forwarding of the data packet depending on whether the data packet requires authentication.

The terminal <NUM> may include an access control application <NUM>, which manages network access of an application stored in the terminal <NUM>, and a network driver (not shown). For example, when an event that a target application <NUM> (e.g., an application (one of 110a to 110d) of <FIG>) included in the terminal <NUM> accesses the destination network <NUM> occurs, the access control application <NUM> may determine whether access of the target application <NUM> is possible. When the access of the target application <NUM> is possible, the access control application <NUM> may transmit a data packet to the gateway <NUM> through the tunnel <NUM>. As another example, the access control application <NUM> may determine whether authentication is required depending on the target application <NUM> and the destination network <NUM> (e.g., IP or port information). When the authentication is required, the access control application <NUM> may not transmit a data packet until the authentication is completed. The access control application <NUM> may control the transmission of a data packet through a kernel including an operating system and a network driver within the terminal <NUM>.

<FIG> is a functional block diagram illustrating a database stored in a controller (e.g., the controller <NUM> of <FIG>), according to various embodiments. <FIG> illustrates only a memory <NUM>. However, a controller may further include a communication circuit (e.g., a communication circuit <NUM> of <FIG>) for communicating with an external electronic device (e.g., the terminal <NUM> or the gateway <NUM> in <FIG>) and a processor (e.g., a processor <NUM> of <FIG>) for controlling overall operations of the controller.

Referring to <FIG>, the controller may store, in the memory <NUM>, databases <NUM> to <NUM> for controlling network access and data transmission.

The access policy database <NUM> may include information associated with a network, service, and/or authentication that an identified network, an identified terminal, an identified user, an identified application, or an unidentified user (e.g., a guest) is capable of accessing. For example, when a request for access to the destination network is received from the terminal, the controller may determine whether the identified network (e.g., a network to which the terminal belongs), terminal, user (e.g., a user of the terminal), and/or application (e.g., an application included in the terminal) is capable of accessing a destination network, whether the authentication for them is required, and an authentication method, based on the access policy database <NUM>.

The tunnel policy database <NUM> may include an encryption method, encryption level information, and the type of a tunnel, which is to be connected between a source node (e.g., a terminal) and a gateway present on the boundary of a network on a connection path. For example, when a request for the access to the destination network is received from a terminal, the controller may provide the terminal with an optimal tunnel for accessing the destination network and information about the optimal tunnel based on the tunnel policy database <NUM>.

The blacklist policy database <NUM> may include a policy for permanently or temporarily blocking the access of a specific terminal. The blacklist policy database <NUM> may be generated based on information (e.g., at least one of a terminal identifier (ID), an IP address, a media access control (MAC) address, or a user ID) identified through the risk level, occurrence period, and/or behavioral analysis of a security event among security events periodically collected at a terminal or gateway.

The blacklist database <NUM> may include a list of at least one of a terminal, an IP address, a MAC address, or a user blocked based on the blacklist policy database <NUM>. For example, when identification information of the terminal requesting for access to the destination network is included in the blacklist database <NUM>, the controller may isolate the terminal from the destination network by denying the access request of the terminal.

The control flow table <NUM> is an example of a session table for managing a flow (e.g., a control flow) of a control data packet generated between a terminal and a controller. When the terminal successfully accesses the controller, the control flow information may be generated by the controller. The control flow information may include at least one of identification information of the control flow, an IP address, a terminal ID, or a user ID which is identified during access to the controller or authentication for the controller. For example, when a request for the access to the destination network is received from the terminal, the controller may search for the control flow information through control flow identification information received from the terminal and then may map at least one of an IP address, a terminal ID, or a user ID included in the found control flow information onto the access policy database <NUM>. Accordingly, the controller may determine whether access of the terminal is possible and whether to generate a tunnel. When enhanced authentication for a specific terminal (or an application or a destination network) is required, authentication request information may include an authentication method, an authentication token, and/or an authentication target.

According to an embodiment, the control flow may have an expiration time. The terminal needs to update the expiration time of the control flow. When the expiration time is not updated during a specific time, the control flow (or the control flow information) may be removed. Besides, when it is determined, depending on the security event collected from the terminal or gateway, that there is a need for immediate access blocking, the controller may remove the control flow depending on an access termination request of the terminal. Because the pre-generated tunnel and data flow are also removed when the control flow is removed, the terminal may be blocked from accessing to the network.

The tunnel table <NUM> is a table for managing a tunnel connected between the terminal and the gateway. For example, the tunnel may be generated in units of devices or IPs. When a tunnel is generated between the terminal and the gateway, the tunnel table <NUM> may include tunnel identification information, control flow identification information when the tunnel is dependent on the control flow, a tunnel end point (TEP), a tunnel start point (TSP), a tunnel algorithm, a tunnel type, and/or additional information for managing the tunnel.

The data flow table <NUM> is a table for managing a flow (e.g., a data flow) through which the detailed data packet is transmitted between the terminal and the gateway. The data flow may be generated in units of TCP sessions, in units of source terminal applications, or in more detailed units within a tunnel generated in units of terminals or IPs. The data flow table <NUM> may include data flow identification information, control flow identification information when the data flow is dependent on the control flow, an application ID for determining whether a data packet transmitted from the terminal is an authorized data packet, a destination IP address, and/or a service port. Also, the data flow table <NUM> may include identification information of a tunnel, through which a data flow is to be used. Moreover, the data flow table <NUM> may include a header (or header information) for determining whether a data packet is valid. Furthermore, the data flow table <NUM> may further include whether a data flow header, which is authentication information, is inserted into a data packet, a method of inserting a header, whether the authentication of a data flow is required, an authentication state of a data flow, and/or an authentication expiration time of a data flow.

<FIG> is a functional block diagram of a terminal (e.g., the terminal <NUM> of <FIG>), according to various embodiments.

Referring to <FIG>, a terminal may include the processor <NUM>, a memory <NUM>, and the communication circuit <NUM>. According to an embodiment, the terminal may further include a display <NUM> for interfacing with a user.

The processor <NUM> may control overall operations of the terminal. In various embodiments, the processor <NUM> may include a single processor core or may include a plurality of processor cores. For example, the processor <NUM> may include a multi-core such as a dual-core, a quad-core, a hexa-core, or the like. According to embodiments, the processor <NUM> may further include a cache memory positioned inside or outside the processor <NUM>. According to embodiments, the processor <NUM> may be configured with one or more processors. For example, the processor <NUM> may include at least one of an application processor, a communication processor, or a graphical processing unit (GPU).

All or part of the processor <NUM> may be electrically or operatively coupled with or connected to another component (e.g., the memory <NUM>, the communication circuit <NUM>, or the display <NUM>) within the terminal. The processor <NUM> may receive a command from other components of the terminal, may interpret the received command, and may perform calculations or process data depending on the interpreted command. The processor <NUM> may interpret and process messages, data, instructions, or signals received from the memory <NUM>, the communication circuit <NUM>, or the display <NUM>. The processor <NUM> may generate new messages, data, instructions, or signals based on the received messages, data, instructions, or signals. The processor <NUM> may provide the processed or generated messages, data, instructions, or signals to the memory <NUM>, the communication circuit <NUM>, or the display <NUM>.

The processor <NUM> may process data or signals, which is generated by a program and occurs in a program. For example, the processor <NUM> may request instructions, data, or signals from the memory <NUM> to execute or control a program. The processor <NUM> may write (or store) or update instructions, data, or signals to the memory <NUM> to execute or control the program.

The memory <NUM> may store instructions for controlling the terminal, control command codes, control data, or user data. For example, the memory <NUM> may include at least one of an application program, an operating system (OS), middleware, or a device driver.

The memory <NUM> may include one or more of a volatile memory or a non-volatile memory. The volatile memory may include a dynamic random access memory (DRAM), a static RAM (SRAM), a synchronous DRAM (SDRAM), a phase-change RAM (PRAM), a magnetic RAM (MRAM), a resistive RAM (RRAM), a ferroelectric RAM (FeRAM), and the like. The non-volatile memory may include a read only memory (ROM), a programmable ROM (PROM), an electrically programmable ROM (EPROM), an electrically erasable programmable ROM (EEPROM), a flash memory, and the like.

The memory <NUM> may further include nonvolatile media (medium) such as a hard disk drive (HDD), a solid state disk (SSD), an embedded multimedia card (eMMC), and universal flash storage (UFS).

According to an embodiment, the memory <NUM> may store some of information included in a memory (e.g., the memory <NUM> of <FIG>) of the controller. For example, the memory <NUM> may store the tunnel table <NUM> and the data flow table <NUM> that are described with reference to <FIG>.

The communication circuit <NUM> may establish a wired or wireless communication connection between the terminal and an external electronic device (e.g., the controller <NUM> or the gateway <NUM> of <FIG>) and may support communication execution through the established communication connection. According to an embodiment, the communication circuit <NUM> may include a wireless communication circuit (e.g., a cellular communication circuit, a short-range wireless communication circuit, or a global navigation satellite system (GNSS) communication circuit) or a wired communication module (e.g., a local area network (LAN) communication circuit or a power line communication circuit) and may communicate with the external electronic device by using a corresponding communication circuit among them through the short-range communication network such as a Bluetooth, a WiFi direct, or an infrared data association (IrDA)) or the long-distance communication network such as a cellular network, an Internet, or a computer network. The above-mentioned various communication circuits <NUM> may be implemented into one chip or may be respectively implemented into separate chips.

The display <NUM> may output content, data, or a signal. In various embodiments, the display <NUM> may display image data processed by the processor <NUM>. In embodiments, the display <NUM> may be configured with an integrated touch screen by being coupled with a plurality of touch sensors (not shown) capable of receiving a touch input or the like. When the display <NUM> is configured with a touch screen, the plurality of touch sensors may be disposed above the display <NUM> or below the display <NUM>.

<FIG> illustrates an operation of controlling transmission of a data packet, according to various embodiments.

Referring to <FIG>, the access control application <NUM> may detect a request for access to the destination network <NUM> of the target application <NUM> and then may determine whether the terminal <NUM> or the target application <NUM> is connected to the controller <NUM>. When the terminal <NUM> or the target application <NUM> is not connected to the controller <NUM>, the access control application <NUM> may block transmission of a data packet from a kernel including an operating system or network driver (operation <NUM>). The terminal <NUM> may block the access of a malicious application in the application layer of an OSI layer in advance through the access control application <NUM>.

According to another embodiment, when the access control application <NUM> is not installed in the terminal <NUM> or a malicious application bypasses the control of the access control application <NUM>, an unauthorized data packet may be transmitted from the terminal <NUM>. In this case, the gateway <NUM>, which is present on the boundary of a network, blocks data packets received through an unauthorized tunnel (operation <NUM>), a data packet (e.g., a data packet for generating a TCP session) transmitted from the terminal <NUM> may not reach the destination network <NUM>. In other words, the terminal <NUM> may be isolated from the destination network <NUM>.

<FIG> and <FIG> illustrate an operation of accessing a controller, according to various embodiments. <FIG> shows a signal flow diagram for accessing a controller. <FIG> shows a user interface screen for accessing a controller.

For the terminal <NUM> to connect to a destination network (e.g., the destination network <NUM> in <FIG>), there is a need to be authorized by the controller <NUM>, and thus the access control application <NUM> of the terminal <NUM> may attempt to access a controller of the terminal <NUM>, by requesting the controller <NUM> to generate a control flow.

Referring to <FIG>, in operation <NUM>, the terminal <NUM> may detect a controller access event. For example, the access control application <NUM> is installed and executed within the terminal <NUM>, and then the terminal <NUM> may detect that access to the controller <NUM> is requested, through the access control application <NUM>.

For example, referring to <FIG>, when the access control application <NUM> is executed, the terminal <NUM> may display a user interface screen <NUM> for receiving information necessary to access a controller. The user interface screen <NUM> may include an input window <NUM> for entering an IP or domain of the controller <NUM>, an input window <NUM> for entering a user ID, and/or an input window <NUM> for entering a password. After information about the input windows <NUM> to <NUM> are entered, the terminal <NUM> may detect a controller access event by receiving a button <NUM> that allows an authenticated user to access the controller. As another example, when user authentication of the terminal <NUM> is not yet completed, the terminal <NUM> may detect the controller access event by receiving a button <NUM> that allows an unauthorized user (i.e., a guest) to access the controller.

In operation <NUM>, the terminal <NUM> may make a request for controller access to the controller <NUM> in response to detecting the controller access event. The terminal <NUM> may request controller access through the access control application <NUM>. According to an embodiment, the access control application <NUM> may transmit, to the controller <NUM>, identification information (e.g., a terminal ID, an IP address, or an MAC address) of the terminal <NUM>, the type of the terminal <NUM>, the location of the terminal <NUM>, the environment of the terminal <NUM>, identification information of a network to which the terminal <NUM> belongs, and/or identification information of the access control application <NUM>.

In operation <NUM>, the controller <NUM> may identify whether the terminal <NUM> is accessible, in response to the received request. According to an embodiment, the controller <NUM> may determine whether the terminal <NUM> is accessible, based on a database included in a memory (e.g., the memory <NUM> in <FIG>) of the controller <NUM>. For example, the controller <NUM> may determine whether the terminal <NUM> is accessible, based on whether the information received from the access control application <NUM> is included in the access policy database and whether the identification information of the terminal <NUM> and/or a network to which the terminal <NUM> belongs is included in a blacklist database.

When the terminal <NUM> is accessible, the controller <NUM> may generate a control flow between the terminal <NUM> and the controller <NUM>. In this case, the controller <NUM> may generate control flow identification information in a form of random numbers and then may store the identification information of the terminal <NUM> and/or the network, to which the terminal <NUM> belongs, in a control flow table. Information (e.g., control flow identification information and/or control flow information) stored in the control flow table may be used for user authentication of the terminal <NUM>, information update of the terminal <NUM>, policy check for network access of the terminal <NUM>, and/or a validity check.

When the control flow is generated, in operation <NUM>, the controller <NUM> may transmit, to the terminal <NUM>, a response to the controller access request. In this case, the controller <NUM> may transmit the generated control flow identification information to the terminal <NUM>.

In operation <NUM>, the terminal <NUM> may process a result value depending on the received response. For example, the access control application <NUM> may store the received control flow identification information and then may display a user interface screen indicating that controller access is completed, to the user. When the controller access is completed, a request for network access of the terminal <NUM> to a destination network may be controlled by the controller <NUM>.

According to another embodiment, the controller <NUM> may determine that access of the terminal <NUM> is impossible. For example, when the identification information of the terminal <NUM> and/or the network to which the terminal <NUM> belongs is included in a blacklist database, the controller <NUM> may determine that access of the terminal <NUM> is impossible. In this case, in operation <NUM>, the controller <NUM> may transmit a response indicating that the access of the terminal <NUM> is impossible, without generating a control flow in operation <NUM>.

When receiving a response indicating that the access of the terminal <NUM> is impossible, in operation <NUM>, the terminal <NUM> may output a user interface screen indicating that the access of the terminal <NUM> is impossible, to the user. For example, referring to <FIG>, the terminal <NUM> may display a user interface screen <NUM> through the access control application <NUM>. The user interface screen <NUM> indicates that access of the terminal <NUM> is blocked, and may include a user interface <NUM> for guiding the release of isolation through an administrator (e.g., the controller <NUM>).

<FIG> illustrates a signal flow diagram for user authentication, according to various embodiments.

For the terminal <NUM> to receive a permission to access a destination network, the access control application <NUM> of the terminal <NUM> may receive authentication for a user of the terminal <NUM> from the controller <NUM>. The user authentication shown in <FIG> may be performed independently of the authentication described with reference to <FIG> and <FIG>. For example, user authentication shown in <FIG> may be performed before network access.

Referring to <FIG>, in operation <NUM>, the terminal <NUM> may receive an input for user authentication. For example, the input for user authentication may be a user input for entering a user ID and password. As another example, the input for user authentication may be a user input (e.g., biometric information or multi-factor authentication) for more enhanced authentication.

In operation <NUM>, the terminal <NUM> may make a request for user authentication to the controller <NUM>. For example, the access control application <NUM> may transmit input information for user authentication to the controller <NUM>. When the control flow between the terminal <NUM> and the controller <NUM> is already generated, the access control application <NUM> may transmit the input information for user authentication together with control flow identification information.

In operation <NUM>, the controller <NUM> may authenticate a user based on information received from the terminal <NUM>. For example, the controller <NUM> may determine whether the user is accessible depending on an access policy and whether the user is included in a blacklist, based on a user ID, a password, and/or enhanced authentication information, which are included in the received information, and a database (e.g., the access policy database <NUM> or the blacklist database <NUM> of <FIG>) included in a memory of the controller <NUM>.

When the user is authenticated, the controller <NUM> may add identification information (e.g., user ID) of the user to identification information of a control flow. The added user identification information may be used for the authenticated user's controller access or network access.

In operation <NUM>, the controller <NUM> may transmit information indicating that the user is authenticated, as a response to a user authentication request to the terminal <NUM>.

In operation <NUM>, the terminal <NUM> may process a result value for user authentication. For example, the terminal <NUM> may display a user interface screen indicating that the user authentication is completed, to the user.

According to another embodiment, the controller <NUM> may determine that user authentication is impossible. For example, when identification information of the user is included in a blacklist database, the controller <NUM> may determine that the user authentication is impossible. In this case, in operation <NUM>, the controller <NUM> may transmit, to the terminal <NUM>, information indicating that user authentication is impossible. In operation <NUM>, the terminal <NUM> may display a user interface screen indicating that user authentication has failed.

<FIG>, <FIG>, <FIG>, and <FIG> describe an operation of controlling network access, according to various embodiments. <FIG> illustrates a flowchart of a signal for controlling network access. <FIG> illustrates a user interface screen when network access is blocked.

<FIG> illustrates a user interface screen when network access is permitted. <FIG> illustrates a user interface screen for enhanced authentication.

After the terminal <NUM> is authorized from the controller <NUM>, the terminal <NUM> may guarantee reliable data transmission by controlling network access of other applications stored in the terminal <NUM> through the access control application <NUM> of the terminal <NUM>. In detail, the terminal <NUM> may guarantee more enhanced security by controlling network access of other applications further based on not only an authorized tunnel, but also whether a data flow is authenticated.

Referring to <FIG>, in operation <NUM>, the access control application <NUM> may detect a network access event. For example, the access control application <NUM> may detect that a target application such as a web browser attempts to access a destination network such as the Internet. For example, a user may launch a web browser and may enter and call a web address to be accessed.

In operation <NUM>, the access control application <NUM> may make a request for network access of the target application to the controller <NUM>. In this case, the access control application <NUM> may transmit, to the controller <NUM>, identification information of a target application, an IP of an access target, and/or service port information together with identification information of the control flow generated between the terminal <NUM> and the controller <NUM>.

In operation <NUM>, the controller <NUM> may determine whether a target application is accessible, whether authentication is required, and/or whether a valid tunnel (or an authorized tunnel) for accessing the destination network is present, based on the request received from the access control application <NUM>.

For example, the controller <NUM> may determine whether the target application is accessible, based on whether information (e.g., an ID of the target application, an access target ID, and/or service port information) received from the access control application <NUM> satisfies an access policy corresponding to information (e.g., information of a terminal, a user, and/or a source network) identified in the control flow. When the access of the target application is impossible, in operation <NUM>, the controller <NUM> may transmit, to the terminal <NUM>, a response indicating that access is impossible. In this case, the access control application <NUM> may drop a data packet of the target application and may display a user interface screen indicating that access to the network is impossible.

When access to the target application is possible but enhanced authentication is required, the controller <NUM> may generate authentication request information depending on the enhanced authentication method (e.g., virtual keypad input-based authentication, two-factor authentication between a PC and a smartphone, or two-factor authentication using ARS and SMS) included in the authentication policy and, in operation <NUM>, may transmit a response requesting enhanced authentication to the terminal <NUM>.

When the access to the network is possible and enhanced authentication is not required, the controller <NUM> may determine whether an authorized tunnel is present between the terminal <NUM> and the gateway <NUM>. For example, the controller <NUM> may identify a TEP and/or a tunnel type in a tunnel policy corresponding to a destination network and then may determine whether an authorized tunnel corresponding to the identified TEP is present in a tunnel table. When the authorized tunnel is present, the controller <NUM> may generate data flow information including information for using a pre-generated tunnel. For example, the data flow information may include a tunnel ID of the pre-generated tunnel, an ID of an application (e.g., an access control application or a target application) authorized to manage access between a terminal, which is TSP, and a gateway, which is TEP, an IP or service port of a destination network, and/or header information to be used for an authenticated data packet. The controller <NUM> may transmit the generated data flow information to the terminal <NUM> and the gateway <NUM> (in operation <NUM> and operation <NUM>).

When an authorized tunnel is not present, the controller <NUM> may generate data flow information including information (e.g., a tunnel type, a method, authentication information, and/or the IP and port of TEP) and then may transmit the generated information to the gateway <NUM> and the terminal <NUM> (in operation <NUM> and operation <NUM>).

As another example, when a tunnel, which satisfies a tunnel policy, from among tunnels to be generated between the terminal <NUM> and the gateway <NUM> is not present, in operation <NUM>, the controller <NUM> may notify the terminal <NUM> that network access is impossible. In this case, the access control application <NUM> may drop a data packet of the target application and may display a user interface screen indicating that network access is impossible.

The access control application <NUM> may process a result value depending on the response received in operation <NUM>.

According to an embodiment, when receiving information indicating that network access of the target application is impossible or information indicating that an authorized tunnel is not present, from the controller <NUM>, the access control application <NUM> may drop the data packet and may output a user interface screen indicating that the network access is impossible. For example, referring to <FIG>, the terminal <NUM> may output a user interface screen <NUM> or <NUM> indicating that the access to the destination network is blocked, through the display. The user interface screen <NUM> or <NUM> may include a text <NUM> or a pop-up window <NUM>, which indicates that access is blocked.

According to another embodiment, when information required to generate a tunnel is received from the controller <NUM>, the access control application <NUM> may generate a tunnel to be connected to the gateway <NUM> in operation <NUM> and then may transmit the data packet of the target application through the generated tunnel in operation <NUM>. In this case, the access control application <NUM> may receive a data packet from the destination network and may process data provided by the destination network. For example, referring to <FIG>, the terminal <NUM> may output the screen <NUM> provided from the destination network (e.g., a website), where access is allowed, through a display.

When the generation of a tunnel fails despite attempting to generate a tunnel, the access control application <NUM> may drop a data packet and may display a user interface screen indicating that network access is impossible.

According to another embodiment, when receiving the tunnel ID of the existing tunnel from the controller <NUM>, the access control application <NUM> may transmit a data packet of the target application to the gateway <NUM> through a tunnel corresponding to the tunnel ID in operation <NUM> without performing an additional tunnel generation procedure.

When a response requesting enhanced authentication is received according to another embodiment, in operation <NUM>, the access control application <NUM> may perform enhanced authentication. For example, referring to <FIG>, the terminal <NUM> may output a user interface screen <NUM> indicating that enhanced authentication is required, through a display. Because the enhanced authentication has not been performed or the authentication time has expired, the user interface screen <NUM> may include a pop-up window <NUM> indicating that network access is blocked. The terminal <NUM> may make a request for the enhanced authentication to a user. For example, the terminal <NUM> may output a user interface screen <NUM> that requires authentication (e.g., QR authentication) according to a specified authentication method through a display. Although not shown in <FIG>, the terminal <NUM> may make a request for various types of authentication (e.g., a key-in method, a biometric information input, or multi-factor authentication) in addition to the QR authentication to the user.

When authentication is not required, the access control application <NUM> may perform operation <NUM> or operation <NUM> without performing operation <NUM>.

The access control application <NUM> and the gateway <NUM> may add data flow information received from the controller <NUM> to the data flow table and then may add information about the newly-generated tunnel to a tunnel table.

<FIG> illustrates an embodiment in which the access control application <NUM> directly makes a request for network access to the controller <NUM> in response to detecting a network access event. However, the access control application <NUM> may determine whether valid data flow information is present before the access control application <NUM> requests network access, whether authentication for data flow is valid, and/or whether an authorized tunnel is present, or may check validity of the target application. In addition, the access control application <NUM> may transmit or drop a data packet depending on the determination result and check result. This will be more fully described with reference to <FIG> and <FIG>.

<FIG> illustrates a flowchart of an operation for controlling network access in a terminal, according to various embodiments. Operations described below may be performed through the terminal <NUM> of <FIG>. For example, a terminal may perform operations of <FIG> by executing instructions stored in a memory through a processor. The instructions stored in the memory may be software or programs such as the access control application <NUM> of <FIG>.

Referring to <FIG>, in operation <NUM>, the terminal may detect a network access event. For example, when a user attempts to access a destination network through a target application such as a specific web browser, the terminal may detect the network access event.

In operation <NUM>, the terminal may determine whether a valid data flow is present. For example, the terminal may identify the IP and service port information of a target application requesting access and a destination (or a destination network) and then may determine whether data flow information corresponding to the information identified is present in the data flow table. When there is no valid data flow (i.e., when there is no data flow information corresponding to the identified information), in operation <NUM>, the terminal may drop a data packet.

When the valid data flow is present, in operation <NUM>, the terminal may determine whether the authentication of the corresponding data flow is valid. For example, the terminal may identify the authentication state of the identified data flow (or data flow information). When data flow authentication is required, or the authentication time of a data flow has expired, the terminal may determine that authentication of a data flow is not valid. In this case, in operation <NUM>, the terminal may drop the data packet.

When authentication of a data flow is valid, in operation <NUM>, the terminal may transmit a data packet depending on a data flow policy.

<FIG> illustrates an operation in which the terminal identifies the validity of a data flow and the validity of the data flow authentication. However, according to a further embodiment, the terminal may determine whether an authorized tunnel is present between the terminal and a gateway positioned on the boundary of the destination network. For example, the access control application may determine whether a tunnel corresponding to identification information of the target application and a destination network (e.g., destination IP) is present in the data flow table stored in the terminal. The authorized tunnel may be a tunnel authorized by an external server (e.g., the controller <NUM> in <FIG>). When an authorized tunnel is present, the terminal may transmit a data packet of the target application through the authorized tunnel. When an authorized tunnel is not present, the terminal may drop the data packet.

<FIG> is a flowchart illustrating another operation for controlling network access in a terminal, according to various embodiments. The operation flowchart shown in <FIG> may be performed after operation <NUM> of <FIG>.

When a valid data flow is not present, the authentication of a data flow is not valid, or an authorized tunnel is not present, in operation <NUM>, the terminal may guarantee the integrity and stability of a target application by performing the validity check of the target application. For example, the access control application may determine whether the target application is forged or tampered, or may test a code signing check and/or a fingerprint check. As another example, the access control application may determine whether a target application, an access target IP, and a service port are accessible, based on an access policy database received from an external server. For example, the external server may be a server that manages the network access of a terminal as shown in the controller <NUM> of <FIG>. When the validity check of the target application fails, the terminal may drop a data packet without requesting network access.

When the validity check of the target application is successful, in operation <NUM>, the terminal may make a request for network access to an external server. For example, the terminal may be registered in the external server through the controller access of <FIG> or the user authentication procedure of <FIG>. In this case, a control flow between the terminal and the external server may be generated. According to an embodiment, the terminal may transmit, to the external server, identification information of a target application, IP of an access target, and identification information of a control flow between the terminal and the external server for a network access request.

In operation <NUM>, the terminal may receive data flow information from an external server. The data flow information may include tunnel information required to transmit a data packet, control flow information allocated to the terminal, information indicating whether authentication is required, identification information for checking whether network access is authenticated, and authentication request information (e.g., an authentication method, an authentication token, and/or an authentication target) required for authentication. When enhanced authentication is not required, the data flow information may not include authentication information. When a pre-generated tunnel is present, the data flow information may include information (e.g., a tunnel ID, an ID of an application authorized to manage access between a terminal, which is TSP, and a gateway, which is TEP, an IP or service port of a destination network, and/or header information to be used for an authenticated data packet) associated with the pre-generated tunnel. As another example, when an authorized tunnel is not present, the data flow information may include information (e.g., a tunnel type, a method, authentication information, and/or IP and port of TEP) required to generate a tunnel.

In operation <NUM>, the terminal may perform authentication (or enhanced authentication) for data flow based on the received data flow information. For example, the terminal may make a request for a series of information to a user based on an authentication method indicated by the data flow information and then may obtain enhanced authentication information from the user. For example, virtual keypad input-based authentication, two-factor authentication between a PC and a smartphone, and two-factor authentication using ARS and SMS may be used for the enhanced authentication.

<FIG> illustrates a signal flow diagram for authenticating network access, according to various embodiments.

Referring to <FIG>, in operation <NUM>, the access control application <NUM> included in the terminal <NUM> may obtain enhanced authentication information (e.g., operation <NUM> of <FIG>).

In operation <NUM>, the access control application <NUM> may request network access authentication from the controller <NUM>. For example, the access control application <NUM> may transmit enhanced authentication information to the controller <NUM>. Additionally, the access control application <NUM> may transmit the IP and/or service port information of a target application and an access target. Additionally, the access control application <NUM> may transmit control flow identification information allocated to the terminal <NUM> together with enhanced authentication information.

In operation <NUM>, the controller <NUM> may verify the requested authentication. For example, the controller <NUM> may determine whether the authentication information obtained from the access control application <NUM> is valid, based on the authentication method matched with information (e.g., the IP and/or service port information of the target application and the access target) identified on a control flow. When authentication information is not valid, in operation <NUM>, the controller <NUM> may transmit information indicating that authentication fails, as a response.

When the authentication information is valid, in operation <NUM>, the controller <NUM> may determine whether a target application is accessible and/or whether a valid tunnel (or an authorized tunnel) for accessing the destination network is present, from the access control application <NUM>.

For example, the controller <NUM> may determine whether the target application is accessible, based on whether information (e.g., an ID of the target application, an access target ID, and/or service port information) received from the access control application <NUM> satisfies an access policy corresponding to information (e.g., information of a terminal, a user, and/or a source network) identified in the control flow. When the access of the target application is impossible, in operation <NUM>, the controller <NUM> may transmit, to the terminal <NUM>, a response indicating that access is impossible.

When the access to the target application is possible, the controller <NUM> may determine whether an authorized tunnel is present between the terminal <NUM> and the gateway <NUM>. For example, the controller <NUM> may identify a TEP and/or a tunnel type in a tunnel policy corresponding to a destination network and then may determine whether an authorized tunnel corresponding to the identified TEP is present in a tunnel table. When the authorized tunnel is present, the controller <NUM> may generate data flow information including information for using a pre-generated tunnel. For example, the data flow information may include a tunnel ID of the pre-generated tunnel, an ID of an application (e.g., an access control application or a target application) authorized to manage access between a terminal, which is TSP, and a gateway, which is TEP, an IP or service port of a destination network, and/or header information to be used for an authenticated data packet. The controller <NUM> may transmit the generated data flow information to the terminal <NUM> and the gateway <NUM> (in operation <NUM> and operation <NUM>).

As another example, when a tunnel, which satisfies a tunnel policy, from among tunnels to be generated between the terminal <NUM> and the gateway <NUM> is not present, in operation <NUM>, the controller <NUM> may notify the terminal <NUM> that network access is impossible.

According to an embodiment, when receiving information indicating that network access of the target application is impossible or information indicating that an authorized tunnel is not present, from the controller <NUM>, the access control application <NUM> may drop the data packet and may output a user interface screen indicating that the network access is impossible.

According to another embodiment, when information required to generate a tunnel is received from the controller <NUM>, the access control application <NUM> may generate a tunnel to be connected to the gateway <NUM> in operation <NUM> and then may transmit the data packet of the target application through the generated tunnel in operation <NUM>. When the generation of a tunnel fails despite attempting to generate a tunnel, the access control application <NUM> may drop a data packet and may display a user interface screen indicating that network access is impossible.

<FIG> describe an operation for transmitting a packet into which header information is inserted, according to various embodiments. <FIG> illustrates a structure of a data packet. <FIG> illustrates a flowchart of an operation for transmitting a data packet in a terminal.

A terminal (or an access control application) may manipulate a packet based on the authentication request information, which is received from an external server (e.g., a controller) and which is included in the data flow information. For example, the authentication request information may include whether a data flow header (or header information) that is authentication information is inserted and/or an insertion method. For example, referring to <FIG>, a data packet may include an IP header, a tunnel header, a TCP header, and a payload. The data packet may have a unique tunnel header and location depending on a tunneling algorithm and type. The determination of TCP access and access release may be determined through the TCP header. Whether a data packet is authorized (or valid) may be determined through the data flow header included in the payload. In another embodiment, the data flow header may be inserted at a location (e.g., an IP header) that is advantageous to transmit a data packet. The payload in which the data flow header is inserted may be encapsulated and encrypted.

Referring to <FIG>, in operation <NUM>, the terminal may identify a header insertion method (or an authentication information insertion method) depending on a data flow rule. The header insertion method may be one of a header insertion method for TCP session authentication and a header insertion method for data packet authentication. In an embodiment, before a <NUM>-way handshake process for the first TCP access is performed, the current header insertion method may be a header insertion method for TCP session authentication. After the <NUM>-way handshake process is performed and then a connection is established, the current header insertion method may be a header insertion method for a data packet.

When the header insertion method is used for TCP session authentication, in operation <NUM>, the terminal may insert a header into a payload of each of an SYN packet and an ACK packet. The SYN packet and the ACK packet may be used in the <NUM>-way handshake process for the first TCP access.

When the header insertion method is used for data packet authentication, in operation <NUM>, the terminal may insert a header into the payload of the data packet. For example, the terminal may insert header information included in the data flow information received from the external server into the data packet. When the data packet is encrypted, the terminal may enable the gateway to determine whether the data packet is valid, by inserting a header into the encrypted data packet.

After performing operation <NUM> or operation <NUM>, the terminal may perform fragmentation depending on a maximum transmission unit (MTU) value. The terminal may transmit the encapsulated and encrypted packet (or data packet) to the destination network.

<FIG> illustrates a flowchart of an operation for controlling forwarding (or routing) of a data packet in a gateway, according to various embodiments.

Referring to <FIG>, in operation <NUM>, a gateway may receive a data packet from a terminal.

In operation <NUM>, the gateway may determine whether the data packet is received through a tunnel authorized by an external server (e.g., a controller). When the data packet is not received through the authorized tunnel, in operation <NUM>, the gateway may drop the data packet.

When the data packet is received through the authorized tunnel, in operation <NUM>, the gateway may determine whether the received data packet is valid.

For example, the gateway may determine whether data flow information corresponding to a destination IP and port information, which are included in the received data packet, is present in the data flow table of the gateway. When an access control application of the terminal makes a request for controller access or network access to the controller, the data flow table may be based on the data flow information received by the gateway from the controller.

When the data flow information is present, the gateway may determine whether the identified data flow is an enhanced authentication target. When data flow is not an enhanced authentication target, in operation <NUM>, the gateway may forward a data packet.

When the identified data flow is the enhanced authentication target, the gateway may identify the authentication method. The authentication check method may be based on source IP, based on a TCP header, or based on a payload header. When the authentication check method is based on the source IP, the gateway may determine whether the data flow information matching the source IP of the data packet is present. When the authentication check method is based on the TCP header, the gateway may determine whether a header is present in the payload of each of the SYN packet and the ACK packet for the <NUM>-way handshaker, and then may determine whether the identified header matches the found data flow information. When the authentication check method is based on the payload header, the gateway may determine whether a header is present in the payload of the data packet, and then may determine whether the identified header matches the found data flow information. When the source IP, the TCP header, or the payload header does not match data flow information, the TCP header is not present, or the payload header is not present, the gateway may determine that the received data packet is invalid. In this case, in operation <NUM>, the gateway may drop the data packet.

Additionally, the gateway may identify an authentication expiration time of the data flow information. When the authentication expiration time has expired, the gateway may determine that the data packet is invalid.

When the data packet is received through the authorized tunnel and is a valid data packet, in operation <NUM>, the gateway may forward the received data packet to a destination network.

<FIG> describe an operation for releasing network access, according to various embodiments. <FIG> illustrates a signal flow diagram for releasing network access. <FIG> illustrates a user interface screen for releasing network access.

Referring to <FIG>, in operation <NUM>, the terminal <NUM> may make a request for releasing network access to the controller <NUM>. For example, the terminal <NUM> may transmit, to the controller <NUM>, identification information of a control flow between the terminal <NUM> and the controller <NUM> together with information requesting the release of the network access.

According to an embodiment, the terminal <NUM> may attempt to release the network access in response to a network access release event, such as a user's request, the restart of the terminal <NUM>, or a request of the access control application <NUM>. For example, referring to <FIG>, the terminal <NUM> may receive a user input for selecting an access end button <NUM> from a user interface screen <NUM> output through a display. The terminal <NUM> may identify access termination to the user again by outputting a user interface screen <NUM> including a pop-up window <NUM>. As another example, the terminal <NUM> may promptly perform operation <NUM> without outputting the user interface screen <NUM>.

In operation <NUM>, the controller <NUM> may remove (or release) a control flow corresponding to the received identification information in response to a request of the terminal <NUM>. When the control flow is removed, all tunnels and data flows that are dependent on the control flow may be removed.

In operation <NUM>, the controller <NUM> may request the gateway <NUM> to remove a tunnel and a data flow, which are dependent on the removed control flow. In this case, the controller <NUM> may transmit tunnel information and data flow information that are to be removed.

Claim 1:
A terminal (<NUM>) comprising:
• a communication circuit (<NUM>);
• a processor (<NUM>) operatively connected to the communication circuit (<NUM>); and
• a memory (<NUM>) operatively connected to the processor (<NUM>) and configured to store a target application and an access control application (<NUM>),
• wherein the memory (<NUM>) stores instructions that cause, when executed by the processor (<NUM>), the terminal (<NUM>) to:
• detect a network access event for a destination network (<NUM>) of the target application through the access control application (<NUM>);
• determine whether data flow information corresponding to identification information of the target application and the destination network (<NUM>) and generated from external server is present, through the access control application (<NUM>);
• determine whether authentication of data flow is valid based on a authentication information included in the data flow information, through the access control application (<NUM>);
• when
∘ a valid data flow is not present, or
∘ the authentication of a data flow is not valid, or
∘ an authorized tunnel is not present,
• perform a network connection request to the external server and
• receive the data flow containing authentication information transmitted from the external server, and process a data packet of the target application, when the data flow information does not exist or the authentication of the data flow is invalid; and
• transmit a data packet of the target application, when the data flow information exists and authentication of the data flow is valid; and
• the authentication information includes information for performing an authentication request including authentication method or authentication target.