Differential security service provision method and device for shipping network that uses packet classification based on user authentication
The method and apparatus for providing differential security services in ship networks utilize packet classification based on user authentication through OAuth and OpenID Connect, addressing the challenge of managing complex access and security requirements in ship networks by ensuring tailored security services for each user class.
Patent Information
- Application Number
- JP2024036150
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2023-12-06
- Filing Date
- 2024-03-08
- Publication Date
- 2025-06-18
- Estimated Expiration
- 2044-03-08
Smart Images

Figure 2025091332000001_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to a technology for providing differential security services in a ship network, and more particularly, to a method and apparatus for providing differential security services in a ship network, which can construct a dedicated ship security system using packet classification based on user authentication.
Background Art
[0002] Autonomous ships applying state-of-the-art digital technologies and artificial intelligence in the shipbuilding, marine, and maritime port fields have been introduced. Thus, recently, the need to prepare a security system for the introduction of autonomous ships has increased rapidly.
[0003] In addition, due to the increase in various network connections and information sharing between ships and onshore, and between main systems within ships, the need for cyber security has also increased rapidly. For example, the severity of marine accident damage is more than six times that of road traffic, and there is a risk of secondary damage in the sea, which is the evacuation space during an accident. In particular, since 2017, cyber attacks on operation technology (OT) systems have increased by 900%, and from February to May 2020, cyber attacks across the entire marine industry have increased by four times.
[0004] In addition, due to the characteristics of ships, in order to drive a cyber security device with limited resources, the need for research on a security system optimized for ships has increased rapidly. That is, due to the characteristics of ships that sail for a certain period, a cyber security system must be operated with limited network devices and resources. In addition, in order to use the cyber security gateway that has been used on land in the ship network, it is necessary to improve its efficiency.
[0005] In addition, the ship network needs to consider the integration with the services of evolving next-generation security technologies. That is, in the next-generation security technologies, the scope of application of security technologies has expanded from the network layer to the application layer in one security product, and it is required to provide composite integrated security services rather than single services. However, it is not necessary for all network packets to use all security services.
[0006] Therefore, there is an increasing need to provide differential security services for each user class in a network for specific applications or specific regions, such as a ship network. In that case, it is necessary to provide differential network and security services according to not only the access rights of the system but also the security level, sensitivity, origin, etc. of the packets. For example, there is a need to improve the inefficiency of duplicate checks for repeated access to initially permitted addresses.
Summary of the Invention
Problems to be Solved by the Invention
[0007] The present invention has been derived to meet the requirements of the above-described prior art. The object of the present invention is to provide a method and apparatus for providing differential security services for a ship network using packet classification based on user authentication, which can effectively provide differential security services for each user class in the ship network.
[0008] Another object of the present invention is to provide a method and apparatus for providing differential security services for a ship network using OAuth (open authorization), which can effectively provide differential network and security services according to not only the access rights of the system but also the security level, sensitivity, origin, etc. of the packets.
[0009] Another object of the present invention is to provide a differential security service providing method and apparatus for a ship network that can effectively improve the inefficiency of duplicate checking for repeated access to initially permitted addresses through an extended user authentication process.
Means for Solving the Problems
[0010] A method for providing a differential security service for a ship network according to an aspect of the present invention for solving the above technical problems includes a series of steps of receiving a service request from a user terminal in a first module, returning an ID token and an authentication code to the user terminal in response to the service request, receiving the ID token and the authentication code from the user terminal in a second module, verifying the validity of the ID token, setting a session cookie for the service request when the validity is verified, transmitting an access token request including the authentication code to a third module, and receiving an access token from the third module.
[0011] The first module may be an authentication execution unit, the second module may be a client, and the third module may be a token issuance unit.
[0012] Another aspect of the present invention for solving the above technical problem, a method for providing differential security service for a ship network, is a method for providing differential security service for a ship network by a service provider connected to a client that performs differential security service, including steps of: receiving a service request from a user terminal by an authentication execution unit of the service provider including a processor; returning or issuing an ID token and an authentication code to the user terminal according to the service request by the authentication execution unit; receiving the ID token and the authentication code from the user terminal by the client; verifying the validity of the ID token by the client; setting a session cookie for the service request by the client when the validity is verified; transmitting an access token request including the authentication code to a token issuing unit of the service provider by the client; and receiving an access token from the token issuing unit by the client.
[0013] The method for providing differential security service (hereinafter, also simply referred to as "the method") may further include a step of transmitting, by the client, a resource request including the access token and having an authenticated header to a resource server of the service provider.
[0014] The method may further include a step of confirming, by the resource server, whether it is correct to access the resource according to a range specified by a user of the user terminal in the access token.
[0015] The method may further include a step of receiving, by the client, a response message including resource information and access information for the resource information from the resource server.
[0016] The method may further include transmitting, to the user terminal according to the response message, a service response to the service request.
[0017] The user terminal may be located inside the ship network. Also, the user terminal may be located outside the ship network.
[0018] The method may further include adding, by the authentication execution unit, an additional field or claim to the payload of the ID token when issuing the ID token.
[0019] The claim may include a specific field for setting a unique identifier for distinguishing the user of the user terminal.
[0020] The method may further include obtaining, by the client, user information via the specific field included in the payload.
[0021] The method may further include generating, by the client, a user class management table corresponding to the current session based on a pre-stored user class management table when the validity is verified.
[0022] The user class management table may be shared with the security gateway of the ship network.
[0023] The access token includes extension parameters, the extension parameters include fields for user class and priority, and the fields for user class and priority may define an action by a return value of a cluster tag in the user class management table.
[0024] Another aspect of the ship network differential security service providing apparatus according to the present invention for solving the above technical problems receives a service request from a user terminal, and returns or issues an ID token and an authentication code to the user terminal in response to the service request. An authentication execution unit, receiving the ID token and the authentication code from the user terminal, verifying the validity of the ID token, and when the validity is verified, setting a session cookie for the service request, and transmitting an access token request including the authentication code to a token issuing unit, and a client that receives an access token from the token issuing unit may be included.
[0025] The differential security service providing apparatus may further include a resource server. Here, the client may transmit a resource request including the access token and having an authenticated header to the resource server. Further, the resource server may confirm whether it is correct to access the resource according to the range specified by the user of the user terminal in the access token.
[0026] The client may receive a response message including resource information and access information for the resource information from the resource server, and transmit a service response to the service request to the user terminal according to the response message.
[0027] When issuing the ID token, the authentication execution unit may add an additional field or claim to the payload of the ID token.
[0028] The claim may include a specific field for setting a unique identifier for distinguishing the user of the user terminal.
[0029] When the validity is verified, the client may generate a user class management table corresponding to the current session based on a pre-stored user class management table. Here, the user class management table may be shared with a security gateway of a ship network.
[0030] The access token may include extension parameters. The extension parameters may include fields for user class and priority. Also, the fields for user class and priority may define an action by a return value of a cluster tag in the user class management table.
Advantages of the Invention
[0031] According to the present invention, differential security services can be effectively provided for each user class in a ship network.
[0032] Also, according to the present invention, not only can the access authority of the system be controlled, but also differential network and security services can be effectively provided according to the security level, sensitivity, origin, etc. of the packet.
[0033] Also, according to the present invention, through an extended user authentication process, the inefficiency of duplicate checks for repeated access to an initially permitted address can be effectively improved.
[0034] Also, according to the present invention, by expanding the user authentication function, the authentication method based on the prior art OAuth is improved. That is, by using an access token, without directly performing user authentication, different permissions for various services in the ship network can be effectively granted by packet classification based on user authentication.
[0035] In addition, according to the present invention, by adding a user authentication method based on OpenID Connect and granting permissions after verifying an ID Token, it is possible to provide a differential security service that cannot be forged even if an attacker steals the access token of another user.
[0036] In addition, according to the present invention, after verifying the ID Token, the service is provided so that the client generates a user session or connects to an already generated session using user information, thereby effectively providing a differential security service in the ship network.
[0037] In addition, according to the present invention, efficient management of the user class management table for providing the differential security service becomes possible. In particular, by applying a specific class management table only to a specific user, the service provider can easily manage the user class management table. Also, by granting permissions after performing a process of confirming whether it matches the information queried from the user class management table using the sub claim of the ID Token, efficient management of the differential security service becomes possible.
[0038] In addition, according to the present invention, when a new user is generated or an existing user's account is reset, a new user class management table is generated and the sub claim issued through the ID Token is inserted, so that all security checks can be performed by specifying a specific value for the class field of the class management table. After the security check, the service provider changes the field value, thereby efficiently providing the differential security service.
Brief Description of the Drawings
[0039]
Figure 1
Figure 2
Figure 3
Figure 4
Figure 5
Figure 6
Figure 7
Figure 8
Figure 9
Figure 10
Figure 11
Figure 12
Figure 13
Figure 14
[0040] Since the present invention can be modified in various ways and can have various embodiments, specific embodiments are illustrated in the drawings and described in detail. However, this is not intended to limit the present invention to specific embodiments, and it should be understood that it includes all modifications, equivalents, and alternatives included in the spirit and technical scope of the present invention.
[0041] Terms such as first, second, etc. can be used to describe various components, but the above components should not be limited by the above terms. The above terms are used only for the purpose of distinguishing one component from another. For example, without departing from the scope of the rights of the present invention, the first component may be named the second component, and similarly, the second component may also be named the first component. The term "and / or" includes a combination of a plurality of related described items or any one of the plurality of related described items.
[0042] In the embodiments of the present application, "at least one of A and B" may mean "at least one of A or B" or "at least one of one or more combinations of A and B". Also, in the embodiments of the present application, "one or more of A and B" may mean "one or more of A or B" or "one or more of one or more combinations of A and B".
[0043] When it is mentioned that a certain component is "connected" or "joined" to another component, it should be understood that it may be directly connected or joined to the other component, but there may also be other components between them. On the other hand, when it is mentioned that a certain component is "directly connected" or "directly joined" to another component, it should be understood that there are no other components between them.
[0044] The terms used in this application are merely used to describe specific embodiments and are not intended to limit the present invention. Singular expressions include plural expressions unless the context clearly indicates otherwise. In this application, terms such as "including" or "having" are used to specify the presence of the features, numbers, steps, operations, components, parts, or combinations thereof described in this specification, and it should be understood that they do not preclude the possibility of the presence or addition of one or more other features, numbers, steps, operations, components, parts, or combinations thereof.
[0045] Unless otherwise defined, all terms used herein, including technical and scientific terms, have the same meaning as commonly understood by one of ordinary skill in the technical field to which the present invention belongs. Terms defined in commonly used dictionaries should be interpreted as having a meaning consistent with the meaning in the context of the related art, and should not be interpreted in an idealized or overly formal sense unless clearly defined in this application.
[0046] Hereinafter, preferred embodiments of the present invention will be described in more detail with reference to the accompanying drawings. In order to facilitate the overall understanding when describing the present invention, the same reference numerals are assigned to the same components in the drawings, and redundant descriptions of the same components are omitted.
[0047] FIG. 1 is a diagram for explaining a ship network to which a differential security service providing method according to an embodiment of the present invention can be applied.
[0048] Referring to FIG. 1, the differential security service providing method can be implemented by a computer device that performs access control between lower networks within a ship. The computer device may be referred to as the differential security service providing device 100.
[0049] The lower networks may include an operational technology (OT) network 10, an information technology (IT) network 20, a crew network 30, and the like.
[0050] The OT network 10, the IT network 20, and the crew network 30 can be connected to the differential security service providing device 100 or a network access control channel based on user authentication controlled by this device via their respective gateways (G / W) 11, 21, 31.
[0051] The OT network 10 may include a first gateway (G / W) 11, a plurality of user terminals 14, a sensor 12 connected to a specific user terminal, an actuator 13 connected to a specific user terminal, and the like.
[0052] The IT network 20 may include a second gateway (G / W) 21, a plurality of user terminals 24, and the like.
[0053] The crew network 30 may include a third gateway (G / W) 31, a plurality of user devices 34, and the like.
[0054] The method for providing a differential security service for a ship network is implemented by a network security device based on user authentication so as to control data traffic between lower networks existing within the ship, and such a network security device can be applied at a higher level of the lower networks.
[0055] Specifically, a computer device or a differential security service providing device 100 that implements a method for providing differential security services for a ship network can control access through mutual authentication when exchanging data among an OT network, an IT network, and a crew network.
[0056] In addition, when accessing the ship network from an external network 200, the differential security service providing device 100 can control access to the external network 200 based on user authentication.
[0057] In addition, the differential security service providing device 100 can deny access to data traffic for which the connection is not permitted based on user authentication.
[0058] In FIG. 1, the data flow by the processor or controller of the differential security service providing device 100 is indicated by a solid line, the allowed flow connected by the controller is indicated by a dashed-dotted line, and the non-allowed flow for which the connection is not permitted by the controller is indicated by a dotted line.
[0059] FIG. 2 is a diagram for explaining the network separation structure of the ship network in FIG. 1.
[0060] Referring to FIG. 2, the differential security service providing device 100 for the ship network can separate the lower networks 10, 20, and 30 by an authentication controller agent. The authentication controller agent may include a first agent 50a of a host agent type and a second agent 50b of a gateway type.
[0061] The lower networks may be interconnected by first switches 11a, 21a, 31a provided in each network.
[0062] When the first agent 50a is provided in the server devices 14a, 24a, 34a, it may be called a server agent, and when provided in the user devices 14b, 34b, it may be called a user agent.
[0063] The second agent 50b may be provided at the rear end of each of the second switches 11b, 21b, 31b of the lower networks 10, 20, 30 for the security of the server devices 14c, 34c or user devices in which the first agent 50a is not provided in the server device or user device.
[0064] Thus, the differential security service providing apparatus 100 of the ship network according to the present embodiment separates the lower networks 10, 20, 30 by an authentication controller agent, and can effectively perform access control between these and between these and the external network.
[0065] FIG. 3 is a diagram for explaining the operating principle of the differential security service providing method of the ship network of FIG. 1.
[0066] Referring to FIG. 3, the differential security service providing apparatus 100 can control the access A1 between the authentication device 34d and the gateway 31 by the central authentication service (CAS) server 36. The authentication device 34d includes server devices, user devices, etc., and the authentication device 34d may be provided with a first agent.
[0067] In this case, the differential security service providing apparatus 100 can authenticate the authentication device 34d by using the public key certificate 37b of the authentication device 34d registered in the certificate authority (CA) 37, and permit access to the gateway 31 via a wireless LAN or an internal network. The wireless LAN may be formed by a wireless communication device 35.
[0068] Furthermore, the apparatus 100 that provides the differential security service can support the external communication A2 and enable the authentication device 34d to access a VAST system 38 such as an external network, a database management system, a storage server, and a web server. The gateway 31 and the switch 31c operate based on a certificate such as the public key certificate 37b. The VAST system 38 can include a storage system or a data platform manufactured by VAST Data, Inc. Also, the VAST system 38 can refer to an approach to data-intensive computing that functions as an integrated software infrastructure for capture, cataloging, and refinement. Data is enhanced or stored through real-time deep data analysis and deep learning.
[0069] On the other hand, when an unauthenticated device 34c in a lower network such as a crew network attempts to access the external network A3 via the gateway 31 or the switch 31c, the differential security service providing apparatus 100 can control to block the external communication of the unauthenticated device 34c and restrict the access. The unauthenticated device 34c may be a user device or a server device provided with a first agent, may be a user device or a server device not provided with a first agent, or may be any terminal not identified within a ship.
[0070] According to this embodiment, access for internal communication within the same network and external communication with an external network can be effectively controlled.
[0071] Figure 4 is a flowchart for explaining a registration procedure between an agent and a controller that can be adopted in the method for providing differential security services in the ship network of FIG. 1.
[0072] Referring to FIG. 4, a server agent 150 connected to a controller 100a of a differential security service providing apparatus via a wired and / or wireless network can transmit a registration request message for the registration of the server agent 150 to the controller 100a of the differential security service providing apparatus based on a first certificate 37c (S41, S42).
[0073] Next, the controller 100a can verify the validity of the certificate 37c received through the registration request message (S43) and transmit registration information to the server agent 150 for the confirmation of the server agent 150 (S44). Here, the registration information may include the public key (KEY SA ) of the server agent, a unique identification value or unique identifier capable of identifying the server agent 150, an access token, and the like. The access token may mean a value for verifying whether a right to access a resource is granted.
[0074] Next, the server agent 150 can transmit a connection request message to the controller 100a based on the registration information received from the controller 100a (S45).
[0075] Next, the controller 100a verifies the registration information upon receiving the connection request message (S46), and can transmit the service information available from the server agent 150 to the server agent 150 in order to perform a mutual authentication protocol with the server agent 150 (S47).
[0076] As the mutual authentication protocol, at least one of TLS (transport layer security) or all other network encryption protocols based on mutual authentication corresponding thereto can be used. Also, the service information may include an IP (internet protocol), a port, a service ID, and the like.
[0077] The above-described steps (S41 to S47) are registration procedures performed between the controller 100a and the server agent 150, and may be called the first process (A process) or the server agent registration process.
[0078] On the other hand, a user agent 50 connected to the controller 100a of the differential security service providing apparatus via a wired and / or wireless network can transmit a registration request message for registration of a user device to the controller 100a of the differential security service providing apparatus based on a second certificate 37d (S51, S52).
[0079] Next, the controller 100a validates (S53) the validity of the second certificate 37d received through the registration request message, and can transmit registration information to the user agent 50 for confirmation by the user agent 50 (S54). Here, the registration information may include a key, a unique identification value or identifier capable of identifying the user agent 50, an access token, and the like.
[0080] Next, the user agent 50 can transmit a connection request message to the controller 100a based on the registration information received from the controller 100a (S55).
[0081] Next, the controller 100a verifies the registration information upon receiving the connection request message (S56), and can transmit service information that can be provided by the user agent 50 to the user agent 50 for performing mutual authentication with the user agent 50 (S57). As the mutual authentication, a network encryption protocol based on TLS (transport layer security) or another mutual authentication that can correspond thereto can be used. Also, the service information may include an IP (internet protocol), a port, a service ID, and the like.
[0082] The steps described above (S51 to S57) are registration procedures performed between the controller 100a and the user agent 50, and may be called the second process (B process) or the user device agent registration process.
[0083] According to this embodiment, the registration procedure between the controller and the agent can effectively perform network access control with high security by registering the information of each agent with the controller in order to permit access to agents that are separated from each other. In particular, only when the registration process is completed normally can the subsequent connection process for network access be performed, so that access control on the ship network can be effectively performed.
[0084] FIG. 5 is a flowchart for explaining a connection procedure between an agent and a controller that can be adopted in the differential security service providing method for the ship network of FIG. 1.
[0085] Referring to FIG. 5, the user agent 50 that has completed the registration procedure can transmit the information of the server agent 150 to be connected via the network through the controller 100a. That is, according to the above-described registration procedure, the controller 100a can share the information of the server agent 150 to which the user agent 50 attempts to access.
[0086] Thereafter, the user agent 50 can perform mutual authentication with the server agent 150 through the connection procedure and make a connection via the network.
[0087] Specifically, the user agent 50 can request the controller 100a for information about the server agent 150 to be connected via the network (S58).
[0088] Next, the controller 100a can first confirm the authority of the user agent 50 in response to the connection request message of the user agent 50 (S59). Here, the controller 100a can apply network separation according to the position or network position of the server agent 150 to which the user agent 50 attempts to access.
[0089] Next, the controller 100a can transmit server information or a server agent list for the server agent accessible by the user agent 50 to the user agent 50 via a connection response message corresponding to the connection request message, etc. (S60a).
[0090] At this time, instead of including the registration confirmation information used in the registration procedure of the user agent 50 in the connection response message and transmitting it to the user agent 50, the controller 100a may include new registration confirmation information used in the connection procedure in the connection response message and transmit it to the user agent 50.
[0091] Here, the controller 100a can transmit the connection response message to the user agent 50 and transmit new registration confirmation information to the server agent 150 that the user agent 50 attempts to access (S60b). The new registration confirmation information may mean new authentication information of the existing registration confirmation information.
[0092] Next, the user agent 50 can transmit a connection request message to the server agent 150 based on the server information or the server agent list received from the controller 100a (S61). The connection request message may include new registration confirmation information.
[0093] Here, the server agent 150 can confirm the new registration confirmation information received from the user agent 50 based on the new registration confirmation information previously received from the controller 100a. However, the present invention is not limited to this. The server agent 150 may request the controller 100a for new registration confirmation information in response to the connection request message of the user agent 50 (S62), receive the new registration confirmation information from the controller 100a through the response message (S63), and then be configured to confirm the new registration confirmation information received from the user agent 50 based on the new registration confirmation information received from the controller 100a. In this way, when confirming the authentication information of the user agent 50, the server agent 150 can select any one of the above two methods to perform verification.
[0094] Next, the server agent 150 verifies the information necessary for connecting to the user agent 50 based on the new registration confirmation information (S64), and can perform a mutual authentication protocol procedure with the user agent 50 (S65).
[0095] When the mutual authentication protocol procedure is completed, the user agent 50 can connect to the server agent 150 through user authentication with respect to the server device, whereby the user device and the server device can transmit and receive signals and data to and from each other.
[0096] FIG. 6 is a schematic block diagram of a differential security service providing apparatus for a ship network according to another embodiment of the present invention.
[0097] Referring to FIG. 6, the differential security service providing apparatus 100 for a ship network may include at least one processor 110, a memory 120, and a transceiver 130 connected to a network to perform communication. The at least one processor 110 and the memory 120 may be constituted by at least one controller.
[0098] The transmission / reception device 130 can include a sub-communication system that supports a wired network and a wireless communication module (WCM) 150 that supports a wireless network.
[0099] Furthermore, the differential security service providing device 100 may further include an input interface device, an output interface device, a storage device, etc. Each component included in the differential security service providing device 100 can be connected by a bus and communicate with each other.
[0100] However, each component included in the differential security service providing device 100 may be connected via an individual interface or an individual bus centered around the processor 110 instead of a common bus. For example, the processor 110 may be connected to at least one of the memory 120, the transmission / reception device 130, the input interface device, the output interface device, and the storage device via a dedicated interface.
[0101] The processor 110 can execute program commands stored in at least one of the memory 120 and the storage device. The processor 110 can mean a central processing unit (CPU), a graphics processing unit (GPU), or a dedicated processor for performing the method according to the embodiments of the present invention. The program commands may include at least one command for implementing the differential security service providing method for a ship network.
[0102] Each of the memory 120 and the storage device may be composed of at least one of a volatile storage medium and a non-volatile storage medium. For example, the memory 120 may be composed of at least one of a read only memory (ROM) and a random access memory (RAM).
[0103] FIG. 7 is a diagram for explaining an access token that can be used in a differential security service providing apparatus for a ship network according to another embodiment of the present invention. Further, FIG. 8 is an exemplary diagram for explaining a ship network of a differential security service providing apparatus using the access token of FIG. 7.
[0104] Referring to FIG. 7, the differential security service providing apparatus 100 can authenticate a user for a user terminal by SSO (single sign-on) authentication based on OIDC (openID connect) (S70). Further, the differential security service providing apparatus 100 can perform user integrated authentication for a plurality of users by user authentication based on OIDC. SSO may be called single account login, single authentication, integrated authentication, or the like.
[0105] The above-described user terminal includes a desktop computer, a mobile terminal, a laptop, a personal portable communication terminal, etc., and may simply be displayed as Users. Users may include a first user (user1) belonging to the first lower network of the ship network, a second user (user2) belonging to the second lower network of the ship network, a third user (user3) belonging to the third lower network of the ship network, and a fourth user (user4) belonging to an external network outside the ship network.
[0106] After user authentication is completed, the differential security service providing apparatus 100 can grant an access token 74 to the user 72 for whom user authentication has been completed. Further, the differential security service providing apparatus 100 can attach a class tag to a packet based on the user authentication to which the access token 74 has been granted. The class tag may include class values such as 0, 1, 2, 3, and delimiter characters.
[0107] The differential security service providing apparatus 100 may be configured to manage and process user packets to which a class tag has been attached by the access token 74 based on OAuth (open authorization).
[0108] OAuth includes OAuth2.0. OAuth2.0 is an open standard protocol for granting authorization using an access token. The access token is set to use resources within the scope permitted by the user and may include permission information for the authorization as an arbitrary string value.
[0109] As shown in FIG. 8, the differential security service providing apparatus 100 can provide and manage networking, security services, etc. for the connection between the lower networks 410 and 420 within the ship network 400 and for the connection between the lower network and the external network 200.
[0110] The differential security service providing apparatus 100 can function as a firewall (FW), an intrusion detection system (IDS) that monitors the network and transmits warnings about potential threats to the network administrator, an intrusion prevention system (IPS), etc.
[0111] In particular, the differential security service providing apparatus can provide a differential security service using packet classification based on user authentication.
[0112] FIG. 9 is a diagram for explaining the main operating principle of the differential security service providing apparatus for the ship network of FIG. 8.
[0113] Referring to FIG. 9, the differential security service providing apparatus can monitor the network and provide a differential security service based on the cluster tag in the user packet transmitted in the network. That is, when the user packet passes through all of a plurality of services in order, the differential security service providing apparatus can check the information of the corresponding cluster tag with a router or a switch and process the presence or absence of authentication and the presence or absence of passage.
[0114] For example, exemplifying the priority for each cluster tag, it is as shown in Table 1 below.
[0115]
Table 1
[0116] According to Table 1, for the user packet, when the cluster tag is 0 (class tag: 0), there is no designated priority. When the cluster tag is 1 (class tag: 1), the designated priority is the first or 1. When the cluster tag is 2 (class tag: 2), the designated priority is the second or 2. When the cluster tag is 3 (class tag: 3), the designated priority may be the third or 3.
[0117] In the above-described case, when the differential security service providing apparatus processes the packets received in a certain unit of time, it can provide a differential security service by packet classification. For example, when a set of packets 82 including user1 packets of the first user, user2 packets of the second user, user3 packets of the third user, and user4 packets of the fourth user enter in the described order in a certain unit of time, the differential security service providing apparatus can change the data processing procedure based on the priority queue (S90, S92).
[0118] That is, when each user packet has a priority queue as shown in FIG. 7, the differential security service providing apparatus can change the data processing procedure of the user packet 84 in order to process the packets in the described order, such as the user3 packet, the user4 packet, the user2 packet, and the user1 packet (S92).
[0119] On the other hand, according to still another embodiment of the present invention, the differential security service providing apparatus for a ship network may be configured to perform SSO (single sign on) authentication based on OIDC (openID connect).
[0120] First, the settings for OIDC are as follows. OIDC can mean an authentication layer created using OAuth (open authorization), which is an authorization grant protocol. OIDC may also be called open ID connection or open ID-based authentication.
[0121] OAuth is a standard protocol that allows third - party clients to receive delegated authorization to access specific user data on various online platforms such as KakaoTalk (registered trademark), Google (registered trademark), Facebook (registered trademark), Twitter (registered trademark), and may include OAuth 2.0. That is, in OAuth 2.0, an authorization server is a server that authenticates the resource owner and issues an access token to the client, and a resource server may mean a server that has resources such as KakaoTalk, Google, Facebook, and Twitter. The authorization server and the resource server may be composed of separate servers, but are not limited to this and may be composed of one server.
[0122] The above - mentioned third - party client, or simply the client, may refer to the differential security service of this embodiment or may refer to the differential security service providing device.
[0123] An access token indicates a token that is set to use only the resources within the scope permitted by the user. The access token issued by OAuth is a token that temporarily permits specific permissions and does not contain user information.
[0124] In this embodiment, the function of the access token is confirmed and utilized. That is, OIDC may be configured to be responsible for authentication at the upper layer of the OAuth 2.0 protocol. Therefore, the differential security service providing device may be configured to verify the identity of the user to the client using OIDC and obtain basic user information.
[0125] Also, in this embodiment, an ID token is used. The ID token is a security token that contains the authentication information of a user configured in the JWT (JSON web token) format. The format of the ID token includes a header, a payload, and a signature. When the ID token is obtained, the differential security service providing apparatus of this embodiment can obtain the user information encoded in the payload part and use this to provide a differential security service for the user.
[0126] The OIDC of this embodiment may be configured to operate according to the provisions of a standard document that defines the use of JWT in order to request an OAuth2.0 access token during client authentication. The standard document may include the IETF (Internet Engineering Task Force) RFC (Request for Comments) 7523 document and the 6749 document. The 6749 document defines the authentication framework of OAuth2.0.
[0127] OAuth2.0 can limit the access scope of a client to user resources according to the scope permitted by the user. An example of an ID token of OIDC configured in the JWT format for this purpose will be described below.
[0128] FIG. 10 is an exemplary diagram for explaining an ID token for SSO authentication based on OIDC that can be adopted by the differential security service providing apparatus of this embodiment.
[0129] Referring to FIG. 10, when OIDC receives a signal or message containing the value "openid" within the scope permitted by the OAuth2.0 user, it can return information regarding user authentication together with an access token to a JWT called an ID token.
[0130] As illustrated on the left side of FIG. 10, the OIDC JWT90 corresponding to the ID token can have a first part 90a, a second part, and a third part 90c. The second part is the part located between the first part 90a and the third part 90c. That is, the ID token including the first to third parts may be composed of a single character string with a full stop as the delimiter character. The first part can correspond to the header, the second part can correspond to the payload, and the third part can correspond to the signature respectively.
[0131] When decoding (S100) the OIDC JWT90, as illustrated on the right side of FIG. 10, the decoded ID token 92 composed of a header, a payload, and a signature can be confirmed.
[0132] FIG. 11 is an exemplary diagram for explaining an ID token that can be adopted for SSO authentication based on OIDC in the present embodiment.
[0133] Referring to FIG. 11, the ID token is a JWT or a JSON web token, and is an encoded token including three types of information: a header, a payload, and a signature. Therefore, in the differential security service providing apparatus, after obtaining the ID token 94, the client can determine or set whether to acquire the user information encoded in the payload part.
[0134] When issuing an ID token, the differential security service providing apparatus can configure claims in the ID token for user authentication management. The claims can include a plurality of fields or sub-claims.
[0135] The main claims are as shown in Table 2.
[0136]
Table 2
[0137] As shown in Table 2, the main claims include iss, sub, aud, exp, iat, and other values can be added to the claim field. The other values may include, for example, email, address, phone number, etc.
[0138] In the main claim, iss indicates the token issuer that issued the ID token, sub indicates the unique identifier for distinguishing users, aud indicates the client that requests the token, that is, the identifier (identification, ID) of the differential security service or the differential security service providing device, exp indicates the expiration time of the ID token, and iat indicates the time when the ID token was issued.
[0139] The differential security service providing device can authenticate a user based on the first information for the token issuer recorded in the "iss" field in the received ID token 94, that is, the second information for the email address recorded in the "https: / / server.example.com" and "email" fields, that is, "jane@example.com".
[0140] According to this embodiment, the differential security service providing device or the differential security service it provides can effectively authenticate a user using the client information of such an ID token.
[0141] The differential security service providing device of this embodiment can expand the differential security service by granting user permissions using extended parameters in addition to the above-mentioned ID token.
[0142] FIG. 12 is an exemplary diagram of extended parameters for user class management that can be adopted for OIDC-based SSO authentication in this embodiment.
[0143] When an authentication server or an authorization server issues a valid access token or ID token based on OAuth 2.0, if the response parameter extension is defined for the token, the differential security service providing device can be configured to perform user class management according to the definition of the extended response parameter.
[0144] Here, the authentication server or the authorization server can be implemented by at least a part of the gateway of the ship network, the server device connected to such a gateway, and the user device.
[0145] More specifically, as shown in FIG. 12, the response message 96 includes an extended parameter 98, and the extended parameter 98 may include items for the user class, items for the class information, and items for the constraints.
[0146] In this embodiment, the user class may include an identifier displayed as a priority, for example, the number 1, the class information may include an identifier indicating a specific internal sub-network, for example, the number 3, and the constraints may include an identifier or related information indicating the access restricted area or the location of the client in the accessible area, for example, location: boston (!location:boston), but is not limited thereto.
[0147] To show the main fields of the above-mentioned extended parameter 98 in more detail, it is as shown in the extended parameter list in Table 3 below.
[0148]
Table 3
[0149] According to this embodiment, by further using extension parameters, differential security services can be more effectively operated and managed by user classes in a security gateway that provides multiple security services such as UTM() or through a security gateway.
[0150] FIG. 13 is a flowchart for explaining the OIDC-based SSO authentication of this embodiment.
[0151] Referring to FIG. 13, the OIDC-based SSO authentication process of the differential security service providing apparatus for a ship network is described as follows.
[0152] First, the client 140 can complete registration so that the user can be authenticated in order to use the service provider 170 in advance (S130). The client 140 may mean a means for providing a differential complement service by packet classification based on user authentication in a ship network or a component that performs a function corresponding to such a means. In other words, the client 140 may mean any one of various conventional online services that may include a differential complement service.
[0153] When the registration is completed, the client 140 can be in a state where information such as a client ID, a client password (client secret or client password), and a user class management table required for user authentication can be provided from the service provider 170. Here, the service provider 170 may be called an OpenID provider or an OpenID authentication service provider.
[0154] Next, as the resource owner, user 210 can request access rights or services from the authentication execution unit 172 corresponding to at least a part of the service provider 170, particularly the authentication server and the authorization server, when the client 140 is in use. For example, the user can request access rights or services through an authentication screen required for the authentication execution unit 172, such as login and input of an authentication number (S131). That is, the authentication execution unit 172 includes an authentication server based on OAuth2.0 and can receive a service request from the user 210 via the OAuth2.0 protocol.
[0155] Here, the user 210 may be referred to as the resource owner and may include a user terminal. The user terminal may be a first node, a first server, or a first communication terminal located on the ship network, or may be a fourth node, a fourth server, or a fourth communication terminal on an external network located outside the ship network.
[0156] After the user authentication is completed, the authentication execution unit 172 of the service provider 170 can return an ID token and an authorization code to the user. At this time, the ID token may include an electronic signature, abbreviated as a signature.
[0157] Next, the user 210 is moved to the location pointed to by the redirect URI (uniform resource identifier), and in this process, the ID token may be transmitted to the client 14 (S133). That is, the client 140 may be transmitted the ID token by the user 210 moving through the redirect URI.
[0158] Next, the client 140 can verify the validity of the ID token (S134). Also, the client 140 can set the cookie for the session (S134). In this step, the client 140 can verify the signature of the ID token using the public key of the token issuer included in the ID token. This process is a process of verifying the validity of the ID token to operate the differential security service, and user authentication with differential classes can be performed based on the user class management table.
[0159] At this time, the client 140 can verify the signature of the ID token using the public key of the token issuer within the ID token.
[0160] Also, the client 140 can confirm whether the token was issued by a trustworthy authentication server based on the "iss" claim in the payload part of the ID token.
[0161] Also, the client 140 can verify whether the "aud" claim matches the client's own identifier. This means confirming whether the token was issued for the said client.
[0162] Also, the client 140 can query the user class management table using the "sub" claim. The user class management table may store user information associated with the unique identifier of the user 210. Also, it can be confirmed whether the user information queried in the user class management table matches the information of the "sub" claim. If the information matches, the client 140 can consider that the user has been authenticated by the authentication server.
[0163] On the one hand, if the user class management table is not defined in the "sub" claim, after the client 140 newly generates the class management table, it can add the "sub" claim to the ID token. In this case, the cluster tag of the class management table can be set to 0. When the cluster tag is set to 0, the client 140 can perform all preset security checks on the user 210 who accessed the ship network.
[0164] Here, when the "sub (subject)" claim value is issued by the same authentication server or authentication execution unit 172 in the OIDC (OpenID Connect) protocol, it can always have the same value for the same user. The "sub" claim is the unique identifier of the user 210 and can be used to consistently identify the user 210 within the authentication server.
[0165] Also, when the verification for the user 210 is completed through the ID token, the client 140 can generate a session for the user 210 and operate to maintain the user in an authenticated state.
[0166] Next, the client 140 can request an access token from the token issuance unit 174 (S135). At this time, the parameters included in the access token request include, but are not limited to, an authorization code, and may be further configured to include at least one selected from a client ID, a client secret, etc. The token issuance unit 174 may include a token server based on OAuth2.0.
[0167] Next, the token issuing unit 174 can issue an access token to provide a differential security service and transmit a refresh token response including the issued access token to the client 140 (S136). The access token may be called a refresh token in the sense of an updated token.
[0168] Next, the client 140 can request a resource from the resource server 176 through the issued access token (S137). The resource request message may have an authorized header and include an access token.
[0169] Next, the resource server 176 verifies the validity of the access token received from the client 140 (S138) and can confirm whether it is correct to access the resource according to the scope specified by the user in the access token.
[0170] After that, the resource server 176 can provide a response message including resource information, access information for the resource information, and information such as whether access to the resource information is permitted to the client 140 (S139). The response message may be called a resource response or a resource response message.
[0171] Next, the client 140 can transmit a service response to the service request to the user 210 based on the resource information obtained by the resource response (S140).
[0172] According to the above configuration, when issuing a valid ID token and access token, the differential security service providing apparatus can define a user class management table based on the response parameters of the authentication execution unit 172 corresponding to the authorization server and provide a differential security service.
[0173] At this time, the service provider 170, for example, the ship network administrator, can define the following contents in advance to manage the users connected to the network. That is, the authorization server can define a class management table for managing the access control levels of users. In addition, the authorization server can create and use a list for specific users who do not require another security check.
[0174] In addition, the service provider 170 can create a class table based on an IP address (internet protocol address), port number, protocol, etc. according to preset security requirements.
[0175] Enumerating the class management fields of the class management table that can be adopted by the service provider 170 in this embodiment is as shown in Table 4 below.
[0176]
Table 4
[0177] Referring to Table 4, the registration management field may include information regarding a subject, source address, source port, destination address, destination port, protocol, class, priority, action, etc.
[0178] On the one hand, in this embodiment, the client 14 is described by limiting it to the differential security service, and it is described as having a form separated from the service provider 170 corresponding to the differential security service providing apparatus. However, the present invention is not limited to such a configuration, and it goes without saying that the service provider 170 or the differential security service providing apparatus may be configured to include the client 14.
[0179] In addition, in this embodiment, the service provider 170 has a form that integrally includes an authentication server including an authentication execution unit 172 and a token issuance unit 174. However, the present invention is not limited to such a configuration, and it goes without saying that the authentication server may be separated into another configuration and configured to cooperate with the differential security service providing apparatus including the resource server 176.
[0180] FIG. 14 is an exemplary diagram for explaining the differential security service providing process based on the OIDC SSO of FIG. 13.
[0181] Referring to FIG. 14, the differential security service providing apparatus based on the OIDC SSO can provide a differential security service for each user class by user authentication using an ID token and an access token based on the user authentication.
[0182] When an administrator, a first user (user1), or a malicious user (devil) accesses the ship network having an ID token, the differential security service providing apparatus can block the access of the malicious user to the ship network by verifying the ID token. Here, the malicious user (devil) may be a user having a stolen access token.
[0183] More specifically, when an access request or service request including an ID token is received from an administrator or user by the service provider 100b, the authentication execution unit of the service provider 100b can verify the ID token (S142).
[0184] To verify the ID token, the service provider 100b can compare the information in the ID token with the information in the predefined user class management table 102 and generate a user class management table 104 for the current traffic as a comparison result (S143). The user class management table 104 may be shared with the security gateway 300 of the ship network.
[0185] Next, the service provider 100b can issue an access token only for the service request for which user verification has been completed (S144). After that, the service provider 100b can provide the access token to the security gateway 300 of the ship network.
[0186] Therefore, the security gateway 300 can differentially perform security monitoring actions such as performing all security checks on the packets of the authenticated user transmitted between the ship network by the user class management table (S145), passing the security check (S146), or performing some security checks (S147).
[0187] According to the above-described embodiments, by using the SSO authentication technology based on OIDC, an ID token can be added at the time of service request, and user authentication can be effectively performed. Also, by using the user information for which authentication is requested, that is, the subject claim of the ID token, in the user class management table for the differential security service, the differential security service can be effectively provided. Further, by performing user authentication and granting permissions through comparison between the subject claim of the ID token and the subject field of the user class management table during the user authentication process, the efficiency of the service can be greatly improved.
[0188] The operations of the method according to the above-described embodiments of the present invention can be embodied as a computer-readable program or code on a computer-readable recording medium. A computer-readable recording medium includes any type of recording device in which information that can be read by a computer system is stored. Also, the computer-readable recording medium may be distributed across a computer system connected by a network, and a computer-readable program or code may be stored and executed in a distributed manner.
[0189] Also, the computer-readable recording medium may include a hardware device specifically configured to store and execute program instructions, such as ROM, RAM, flash memory, etc. The program instructions may include not only machine language code created by a compiler but also high-level language code executable by a computer using an interpreter or the like.
[0190] While some aspects of the invention have been described in the context of an apparatus, it can also be described by a corresponding method, where a block or apparatus corresponds to a method step or a feature of a method step. Similarly, aspects described in the context of a method can also be shown as corresponding blocks or items, or features of a corresponding apparatus. Some or all of the method steps can be performed by (or with) a hardware device such as, for example, a microprocessor, a programmable computer, or an electronic circuit. In some embodiments, at least one or more of the most important method steps can be performed by such a device.
[0191] In embodiments, a programmable logic device (e.g., a field-programmable gate array) can be used to perform some or all of the functions of the methods described herein. In embodiments, a field-programmable gate array can operate with a microprocessor to perform one of the methods described herein. Generally, it is preferred that the methods be performed by hardware devices.
[0192] Although described above with reference to embodiments, those skilled in the art will understand that the present invention can be variously modified and changed without departing from the spirit and scope of the invention as set forth in the following claims.
Claims
1. A method for providing differential security services in a ship network by a service provider connected to a client that provides differential security services, comprising the steps of: receiving a service request from a user terminal by an authentication execution unit of a service provider including a processor; returning or issuing an ID token and an authentication code to the user terminal in response to the service request by the authentication execution unit; receiving, by the client, the ID token and the authentication code from the user terminal; verifying, by the client, the validity of the ID token; setting a session cookie for the service request if the validity is verified by the client; transmitting an access token request including the authentication code to a token issuing unit of the service provider by the client; receiving, by the client, an access token from the token issuer.
2. 2. The method of claim 1, further comprising transmitting, by the client, a resource request having an authenticated header including the access token to a resource server of the service provider.
3. The method for providing differential security services in a ship network as described in claim 2, further comprising a step of confirming by the resource server whether it is correct to access the resource based on the range specified by the user of the user terminal in the access token.
4. The method for providing differential security services in a ship network as claimed in claim 3, further comprising the step of receiving, by the client, a response message from the resource server, the response message including resource information and access information for the resource information.
5. 5. The method of claim 4, further comprising the step of transmitting a service response to the service request to the user terminal in response to the response message.
6. The method for providing differential security services in a ship network according to claim 1 , wherein the user terminal is located inside or outside the ship network.
7. 2. The method for providing differential security services in a ship network as described in claim 1, further comprising the step of adding additional fields or claims to the payload of the ID token by the authentication executor when issuing the ID token.
8. 8. The method for providing differential security services in a ship network as claimed in claim 7, wherein the claim includes a specific field for setting a unique identifier for identifying a user of the user terminal.
9. 9. The method for providing differential security services in a ship network as claimed in claim 8, further comprising the step of obtaining, by the client, user information via the specific field included in the payload.
10. 2. The method for providing differential security services in a ship network as described in claim 1, further comprising the step of generating a user class management table corresponding to a current session based on a pre-stored user class management table when the validity is verified by the client.
11. The method for providing differential security services in a ship network according to claim 10, wherein the user class management table is shared by security gateways in the ship network.
12. The access token includes an extension parameter; The extended parameters include fields for user class and priority; The method of claim 11, wherein the fields for user class and priority define actions according to return values of class tags in the user class management table.
13. A ship network differential security service providing device, comprising: an authentication execution unit that receives a service request from a user terminal and returns or issues an ID token and an authentication code to the user terminal in response to the service request; a client that receives the ID token and the authentication code from the user terminal, verifies the validity of the ID token, and if the validity is verified, sets a session cookie for the service request, transmits an access token request including the authentication code to a token issuing unit, and receives the access token from the token issuing unit.
14. Further comprising a resource server, The client transmits a resource request to the resource server with an authenticated header including the access token; The differential security service providing device for a ship network as described in claim 13, wherein the resource server verifies whether it is correct to access the resource based on the range specified by the user of the user terminal in the access token.
15. The device for providing differential security services in a ship network as described in claim 14, wherein the client receives a response message including resource information or access information for the resource information from the resource server, and transmits a service response to the service request to the user terminal in response to the response message.
16. The ship network differential security service providing device of claim 13, wherein the authentication executor adds additional fields or claims to the payload of the ID token when issuing the ID token.
17. The device for providing differential security services in a ship network as claimed in claim 16, wherein the claim includes a specific field for setting a unique identifier for identifying a user of the user terminal.
18. When the validity is verified, the client generates a user class management table corresponding to the current session based on a pre-stored user class management table; The differential security service providing device of a ship network as described in claim 17, wherein the user class management table is shared by security gateways of the ship network.
19. The access token includes an extension parameter; The extended parameters include fields for user class and priority; The device for providing differential security services in a ship network as claimed in claim 13, wherein the fields for user class and priority define the action of security services for each class according to the return value of the class tag in the user class management table.
Citation Information
Patent Citations
Authentication authorization server, resource server, authentication approval system, authentication method and program
JP2018163616A
Authentication permission system, authentication permission server, authentication method and program
JP2018180692A
Tenant self-service troubleshooting for multi-tenant identity and data security management cloud services
JP2019531534A
Method and system for seamless single sign-on (SSO) for native mobile-application initiated open-id connect (OIDC) flow and security assertion markup language (SAML) flow
JP2020126602A
Ship network approach control method and apparatus
JP2023076798A