Route control system and route control method

Abstract

To prevent unauthorized use of a device equipped with a SIM.SOLUTION: A route control system includes a first authentication unit that performs first authentication regarding a device using a unique ID of a SIM installed in a device to be route controlled, a second authentication unit that performs second authentication regarding the device using a device management protocol, and a route control unit that connects the device to the second authentication unit via a first route when the first authentication is successful, and connects the device to a target server via a second route when the second authentication by the second authentication unit is successful.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] The present invention relates to a technology for authenticating devices.

Background Art

[0002] Entering the 5G / IoT era, efforts to promote DX in IoT (Internet of Things) using mobile (e.g., LTE / 5G) technology are becoming active. In particular, by using 5G technology with the characteristics of high speed, large capacity, high reliability, and low latency and a large number of simultaneous connections, it is expected that big data collected from various IoT devices will be analyzed by AI for each industry, and new value will be created in each field.

[0003] On the other hand, it is necessary to manage a huge number of IoT devices installed in various places. In particular, it is necessary to protect IoT devices from SIM swapping, information leakage due to security incidents, and attacks by third parties on IoT devices and servers.

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0005] Mobile (e.g., LTE / 5G) lines are considered to be more secure than Wi-Fi (registered trademark), which is widespread as a wireless line, because they establish a wireless connection through authentication using a tamper-resistant SIM.

[0006] However, because IoT devices are installed in locations that are difficult for humans to manage, there is a risk that IoT devices or SIM cards may be illegally swapped and misused. It should be noted that this type of misuse is not limited to IoT devices, but can occur with any device that uses SIM cards for communication.

[0007] This invention has been made in view of the above points, and aims to provide a technology for preventing the unauthorized use of devices equipped with a SIM card. [Means for solving the problem]

[0008] According to the disclosed technology, a first authentication unit performs a first authentication regarding the device using the unique ID of the SIM installed in the device subject to routing control, Based on LwM2M A second authentication unit performs a second authentication of the device using a device management protocol, A route control unit that, upon successful first authentication, connects the device to the second authentication unit via a first route, and upon successful second authentication by the second authentication unit, connects the device to the target server via a second route, A route control system comprising: The second authentication unit receives authentication key information, which includes the unique ID of the SIM, the unique ID of the device's hardware, and a pre-shared key pre-configured on the device, as an LwM2M bootstrap request from the device, and performs the second authentication by comparing the authentication key information with authentication key information pre-held as device management information. A routing system is provided. [Effects of the Invention]

[0009] According to the disclosed technology, a technology is provided to prevent the misuse of devices equipped with a SIM card. [Brief explanation of the drawing]

[0010] [Figure 1] This is a diagram illustrating the outline of the embodiment. [Figure 2] This diagram shows an example of the system configuration. [Figure 3] This is a sequence diagram used to explain the operation of the system. [Figure 4]It is a diagram showing an example of a sequence in device authentication. [Figure 5] It is a diagram showing an example of information stored in a device management apparatus. [Figure 6] It is a functional configuration diagram of a core network apparatus. [Figure 7] It is a functional configuration diagram of a device management apparatus. [Figure 8] It is a functional configuration diagram of an IoT device. [Figure 9] It is a diagram showing an example of the hardware configuration of a device.

Embodiments for Carrying Out the Invention

[0011] Hereinafter, embodiments (these embodiments) of the present invention will be described with reference to the drawings. The embodiments described below are merely examples, and the embodiments to which the present invention is applied are not limited to the following embodiments.

[0012] In the following description, an IoT device is used as a device to be managed, but this is an example. The technology according to the present invention can also be applied to devices other than IoT devices.

[0013] (Regarding Problems) First, problems regarding the technology according to these embodiments will be described.

[0014] Regarding a huge number of IoT devices installed in various places, it is necessary to defend itself against various illegal risks such as impersonation by SIM swapping, information leakage due to security incidents, and attacks on IoT devices and servers, while being strictly managed by administrators and operators. However, in management, it is necessary to use a simple mechanism that does not increase the burden.

[0015] From the perspective of authentication to prevent unauthorized access from unauthorized devices, in devices that can be mainly operated by "humans" such as personal computers and smartphones, biometric authentication and methods such as 2FA that comprehensively utilize these and conventional authentication methods are becoming increasingly popular, and it is considered that the risk has been reduced compared to IoT devices.

[0016] However, in the case of "things", that is, IoT devices, due to their nature, it is realistically difficult to use an authentication method that requires operation by "humans" each time authentication is performed. Assuming IoT devices targeted at "things", there is a need for a secure, safe and simple authentication method that is as autonomous as possible without the intervention of "human" operations and is controlled from the network side.

[0017] In addition, for the path setting work to the opposing server etc. which is the access destination to which IoT devices should be connected, when targeting a huge number of IoT devices, a huge amount of manual work is required. Therefore, there is a need for a technology that identifies IoT devices connected to the network by the functions on the network side and surely and simply sets the path information of the connection destination.

[0018] On the other hand, conventionally, there is a technology that uses the SIM installed in an IoT device to perform authentication for line connection. Connection using a SIM not registered in the customer management DB of the mobile network is not authorized. Also, since important SIM information is stored in a tamper-resistant area, the risk of leakage of authentication key information etc. can also be avoided.

[0019] Therefore, SIM authentication can ensure higher security compared to MAC address authentication and 802.1x authentication in Wi-Fi (registered trademark) which is still widely popular as a wireless connection.

[0020] However, IoT devices are often installed in locations that are difficult for humans to understand and manage, and some IoT devices may even be moved. As a result, there is a risk that malicious third parties could steal legitimate IoT devices with legitimate SIM cards inserted, remove the legitimate SIM cards, and insert them into fraudulent IoT devices, thereby misusing those devices. This type of fraud is called SIM swapping.

[0021] In other words, SIM authentication alone cannot guarantee the authenticity of IoT devices, so there is a risk, for example, that a fraudulent IoT device could connect to an end user's important internal network.

[0022] (Summary of the embodiment) Therefore, in this embodiment, the authenticity of IoT devices that are truly allowed to connect to a network (e.g., an end-user's internal network) is ensured by using a device authentication mechanism in conjunction with SIM authentication. In this combined SIM authentication and device authentication mechanism, authentication is performed between the IoT device and the authentication device based on the SIM information and the hardware information possessed by the device. As a result, authentication can be performed safely, securely, reliably, and simply without intervention such as human terminal operation.

[0023] The system overview and operation overview of this embodiment will be explained with reference to Figure 1. As shown in Figure 1, the route control system according to this embodiment includes a route control unit 21, a first authentication unit 22, and a second authentication unit 23. The first authentication unit 22 corresponds to the function of performing SIM authentication, and the second authentication unit 23 corresponds to the device management device 200. The route control unit 21 and the first authentication unit 22 are functions included in the core network device 100, which will be described later.

[0024] The first authentication unit 22 performs SIM authentication based on the information of the SIM 11 installed in the IoT device 10. The second authentication unit 23 performs device authentication of the IoT device 10.

[0025] As shown in Figure 1, if both SIM authentication and device authentication are successful for the IoT device 10 equipped with the SIM 11, the route control unit 21 performs route control to connect the IoT device 10 to the target server.

[0026] The target server is, for example, the server to which the IoT device 10 uploads collected information, or the server to which control information is sent to the IoT device 10. If both SIM authentication and device authentication for the IoT device 10 are not OK, the connection is blocked. If both SIM authentication and device authentication for the IoT device 10 are not OK, the IoT device 10 may be kept in the quarantine network (the network of the second authentication unit 23).

[0027] Furthermore, in this embodiment, during the process of verifying the authenticity of the IoT device 10 through SIM authentication and device authentication, the second authentication unit 23 can identify the IoT device 10 based on the SIM information and device information.

[0028] Identifying IoT device 10 means, for example, identifying the type of IoT device 10 (e.g., surveillance camera, AGV, etc.). This "type" allows us to determine the server to which IoT device 10 should connect.

[0029] Therefore, by having the system maintain information that associates the type of IoT device 10 with the server to which it connects, the IoT device 10 can be connected to the appropriate server without having to configure the connection destination for each IoT device 10. For example, if the IoT device 10 is a surveillance camera, it can be connected to a video storage server.

[0030] Information relating the type of IoT device 10 to the connected server is stored in the routing instruction device 500, which will be described later. Alternatively, this information relating the type of IoT device 10 to the connected server may be stored in the device management device 200, which will be described later. Alternatively, this information relating the type of IoT device 10 to the connected server may be stored in the data storage unit of the core network device 100.

[0031] Furthermore, any technology may be used for routing the IoT device 10 to the target server, but for example, 5G network slicing technology can be used.

[0032] When using 5G technology, a tunnel (e.g., GTP tunnel, GRE tunnel) is used as a logical path (logical dedicated communication channel) between the IoT device 10 and the target server (or the UPF connected to that server). By using such a logical dedicated communication channel (5G network slicing technology), it is possible not only to perform routing control with QoS functioning for the content of communications flowing through the dedicated communication channel, but also to prevent the content of communications between the IoT device 10 and the server from leaking to other paths, thereby avoiding security risks.

[0033] Furthermore, in this embodiment, the standard protocol used for device management (referred to as the device management protocol) is reused for device authentication. In this embodiment, LwM2M proposed by OMA is used as the specific device management protocol, but other It is also possible to use device management protocols (e.g., MQTT proposed by OASIS).

[0034] By utilizing device management protocols in device authentication, not only can robust device authentication be achieved, but the device management and monitoring mechanisms within the protocol can also be leveraged, thereby enabling the avoidance of a wider range of security risks.

[0035] This technology makes it possible to prevent unauthorized impersonation of IoT devices, such as SIM swapping, which could not be handled by conventional SIM authentication alone, and enables routing control by identifying the connected IoT device 10. Furthermore, because the aforementioned tunnel is used, information leakage during data transfer to the server can be prevented. In addition, by using the device management protocol, IoT device health monitoring, status monitoring, and FOTA (Firmware update Over The Air) are also possible.

[0036] (Example system configuration) Figure 2 shows an example of a system configuration in this embodiment. The example shown in Figure 2 is an example of applying the technology according to the present invention to a local 5G system. This is just one example, and the technology according to the present invention is not limited to local 5G systems but can also be applied to wide-area (global) 5G systems. Furthermore, the technology according to the present invention is not limited to 5G networks. For example, it can also be applied to 3G, 4G (LTE), and 6G.

[0037] In the system shown in Figure 2, a local 5G system is configured within the factory. The local 5G system includes a local 5G base station and a core network device 100. The core network device 100 includes a 5GC (5G core network). The core network device 100 also includes routing functionality and authentication functionality using a SIM. Routing functionality and authentication functionality using a SIM may be functions included in the 5GC, or they may not be functions included in the 5GC. Note that UPF1-3 may be located outside the core network device 100. The core network device 100 may also be called a network system 100, routing control device 100, routing system 100, network 100, or core network 100.

[0038] The core network device 100 may be a device on which virtual machines or virtual networks are built on one or more physical machines (servers, etc.), or it may be a network (which may also be called a system) configured by connecting one or more physical machines with lines (transmission paths), or it may be a configuration other than these.

[0039] The routing control function in the core network device 100 is a function for establishing and controlling the data connection paths (which may also be called paths, sessions, etc.) of IoT devices 10. The UPF is a device that performs data transfer, etc. The UPF may also be called a transfer device.

[0040] The routing function in the core network device 100 may consist of one device (computer) or multiple devices.

[0041] Furthermore, an AGV (automated guided vehicle) 10A and a camera 10B are shown as examples of IoT devices 10. Both the AGV 10A and the camera 10B have SIM cards installed.

[0042] Furthermore, the system is equipped with a device management device 200, an AGV control server 300, a video storage server 400, and a route instruction device 500. The device management device 200 may also be called a DMS (Device Management System).

[0043] In the example shown in Figure 2, the AGV control server 300 is located within the factory and the video storage server 400 is in the cloud, but this is just one example of a configuration. If low latency is required, the configuration should be considered based on communication requirements, such as placing the servers within the factory. For example, both the AGV control server 300 and the video storage server 400 could be located within the factory, or both could be located in the cloud.

[0044] The device management device 200 includes a function to execute a device management protocol. The device management device 200 also includes a function to manage the hardware unique ID (e.g., IMEI) and SIM unique ID (e.g., IMSI, SUPI) of each IoT device 10 as device management information, and to perform device authentication to check the authenticity of the IoT device 10 using these.

[0045] Each IoT device 10 holds and manages the authentication key information required for SIM authentication, as well as the device management client library and authentication key information required for device authentication. The device management device 200 holds and manages the SIM authentication key information, device management server library, and authentication key for performing device authentication. Both the device management client library and the device management server library are software (programs) for executing the device management protocol, and specific examples will be described later.

[0046] When the routing instruction device 500 receives a connection request for the IoT device 10 from the device management device 200, it configures the core network device 100 for routing (setting a logical path, etc.) so that the IoT device 10 is connected to its target server. The connection request includes, for example, the identification information of the IoT device 10 and the identification information of the target server. The connection request including the identification information of the IoT device 10 and the identification information of the target server may also be called routing control information.

[0047] Furthermore, the route instruction device 500 itself can be implemented using conventional technology. For example, a one-stop construction agent (APIO) can be used as the route instruction device 500.

[0048] Furthermore, the routing instruction device 500 may be considered as a function included within the core network device 100. Alternatively, the functionality of the routing instruction device 500 may be included within the device management device 200.

[0049] In this embodiment, when the SIM authentication of the IoT device 10 is successful, the IoT device 10 is connected to the device management device 200, and the device management device 200 performs device authentication of the IoT device 10.

[0050] If device authentication is successful, the IoT device 10 is connected to the target server. In the example in Figure 2, AGV 10A is connected to AGV control server 300, and camera 10B is connected to video storage server 400. The AGV control server 300 sends control commands to AGV 10A based on sensor information received from AGV 10A, for example. The video storage server 400 stores the video data received from camera 10A.

[0051] (Example of system operation) An example of the system's operation in this embodiment will be explained with reference to Figure 3. Note that the system shown in Figure 3 is assumed to be a 5G system as shown in Figure 2. However, as mentioned above, the technology related to this embodiment is also applicable to systems other than 5G (e.g., 3G, 4G, 6G). A wireless base station exists between the core network device 100 and the IoT device 10, and the IoT device 10 communicates with the core network device 100 via the wireless base station. Note that the processing operations of the part labeled "core network device 100" in Figure 3 mainly focus on the authentication function and routing control function of the core network device 100.

[0052] In S101, the IoT device 10 sends a connection request signal to the core network device 100 that includes the unique ID of the SIM (e.g., IMSI, SUPI). The core network device 100 holds user information (including the unique ID of the SIM) for each user (IoT device), and for example, it authenticates the IoT device 10 (SIM authentication) by comparing the unique ID of the SIM of the relevant user with the unique ID of the SIM received from the IoT device 10 in S101 (S102).

[0053] If SIM authentication in S102 fails, the core network device 100 blocks the connection by sending a signal to the IoT device 10 rejecting the connection. In the example in Figure 3, it is assumed that SIM authentication in S102 was successful.

[0054] The core network device 100 authorizes the IoT device 10 to connect to the quarantine network, sets the route, and in S103 returns a connection response signal to the IoT device 10 indicating authorization for connection to the quarantine network. The connection response signal includes, for example, the identifier of the destination to which the IoT device 10 is connected.

[0055] This identifier is, for example, an identifier (NSSAI: Network Slice Selection Assistance Information) that identifies a network slice corresponding to a quarantine network. The IoT device 10 may also store this identifier in advance as a default identifier for connecting to the quarantine network.

[0056] In the example shown in Figure 3, the transfer device 1 is a device for transferring data to the device management device 200 (e.g., a UPF connected to the device management device 200). In S104 and S105, the IoT device 10 sends a connection request including the above identifier, thereby selecting the transfer device 1 (UPF) for the IoT device 10's communication (session), and the IoT device 10 is connected to the device management device 200.

[0057] In S106, the device management device 200 performs device authentication for the IoT device 10. Also in S106, the device management device 200 identifies the type of IoT device (e.g., surveillance camera, AGV, etc.). Details of S106 will be described later.

[0058] If device authentication in S106 fails, the device management device 200 blocks the connection by, for example, sending a signal to the IoT device 10 to reject the connection. In the example in Figure 3, it is assumed that device authentication in S106 was successful. As a result, both the SIM and the IoT device 10 can be determined to be legitimate, and the authenticity of the IoT device 10 is confirmed.

[0059] In S107 and S108, the device management device 200 notifies the core network device 100, via the routing instruction device 500, of a temporary connection release instruction instructing the core network device 100 to release the connection from the quarantine network, and also notifies it of the network path information (referred to as routing control information) that the connected IoT device 10 should take for communication. The temporary connection release instruction and routing control information together are referred to as a route update instruction.

[0060] In the example shown in Figure 3, the above notification is made via the routing instruction device 500, but this is just one example. The device management device 200 may also include the functions of the routing instruction device 500, allowing the device management device 200 to directly notify the core network device 100. Alternatively, the routing instruction device 500 may be considered as a function within the core network device 100, allowing the device management device 200 to directly notify the core network device 100.

[0061] Upon receiving a route update instruction, the core network device 100 releases the temporary connection route for the quarantine network in S109. The core network device 100 also sets an appropriate route corresponding to the type of IoT device 10, etc., based on the route control information included in the route update instruction. This route setting involves, for example, setting a logical path corresponding to the type of IoT device 10 between the IoT device 10 (or the wireless base station to which the IoT device 10 is connected) and the forwarding device (UPF) connected to the server that is the destination of the communication. This logical path may also be called a "tunnel" or "network slice".

[0062] Regarding network slices, for example, if the IoT device 10 is involved in a service requiring low latency (e.g., autonomous driving control), a low-latency network slice will be configured. If the IoT device 10 is involved in a service requiring high-capacity transmission (e.g., video distribution), a high-capacity network slice will be configured.

[0063] After the temporary connection is released, the IoT device 10 requests a connection to the network (e.g., a 5G line) again by sending a connection request signal in S110. In S111, the core network device 100 authenticates the IoT device 10 using the unique ID of the SIM. Here, we assume that the authentication is successful.

[0064] In S112, the core network device 100 sends a connection response signal to the IoT device 10 containing information authorizing connection to the updated path. This information is, for example, an identifier of the logical path to connect to (e.g., tunnel, network slice).

[0065] In S113 and S114, the IoT device 10 connects to the logical path that it should use. Here, for example, the IoT device 10 secures the resources of the logical path by sending a connection request signal that includes an identifier identifying the logical path of the updated route. Securing the resources of the logical path may also be expressed as establishing the logical path.

[0066] In S115, the IoT device 10 initiates data communication. In the example shown in Figure 3, it is assumed that the forwarding device 3 is connected to the destination server. For example, a packet sent from the IoT device 10 is forwarded to the forwarding device 3 connected to the destination server according to the route set by the core network device 100, and then forwarded from the forwarding device 3 to the destination server. Packets in the reverse direction can also be forwarded to the IoT device 10 via the same route.

[0067] This allows, for example, if IoT device 10 is a surveillance camera, IoT device 10 to communicate with a video storage server in the cloud, and if IoT device 10 is an AGV, IoT device 10 to communicate with an AGV control server located on-premises.

[0068] (Examples) Below, we will explain more specific examples of device authentication operations with reference to the sequence diagram in Figure 4. Figure 4 shows the device authentication sequence after SIM authentication is complete.

[0069] The device authentication sequence in this embodiment is a sequence based on LwM2M (Lightweight M2M), which is an example of a device management protocol.

[0070] As shown in Figure 4, the IoT device 10 has a PSK (Pre-Shared Key) 12, LwM2M Bootstrap information 13, and an LwM2M client 11. The LwM2M client 11 is software (a program) that runs on the IoT device 10.

[0071] Furthermore, the device management device 200 includes LwM2M Bootstrap 201 (which may also be called the LwM2M Bootstrap server), LwM2M server 202, device management information 203 (referred to as device management information 203), and LwM2M server information 204. LwM2M Bootstrap 201 and LwM2M server 202 are software (programs) that run on the device management device 200.

[0072] In S1, the LwM2M client 11 on the IoT device 10 requests a connection to the LwM2M Bootstrap 201 on the device management device 200 based on the LwM2M Bootstrap information. The LwM2M Bootstrap information includes information that identifies the LwM2M Bootstrap 201.

[0073] LwM2M Bootstrap201 compares the LwM2M Bootstrap information held by IoT device 10 with its own information. Once the legitimacy of the information held by IoT device 10 is confirmed, a certificate-based DTLS (Datagram Transport Layer Security) handshake is performed between LwM2M client 11 and LwM2M Bootstrap201 in S2. This establishes a DTLS connection between LwM2M client 11 and LwM2M Bootstrap201. The following S3-S5 operations are performed within this DTLS connection.

[0074] In S3, the LwM2M client 11 sends a Bootstrap Request to the LwM2M Bootstrap 201. In the example in Figure 4, the Bootstrap Request includes the SUPI (Subscription Permanent Identifier), IMEI (International Mobile Equipment Identity), and PSK.

[0075] SUPI is the unique SIM ID read from the SIM of IoT device 10. IMEI is the unique hardware ID of IoT device 10, and may also be called the terminal identification number, manufacturing number, serial number, etc.

[0076] Note that using SUPI, IMEI, and PSK as information to include in the Bootstrap Request is just one example. You may also include IMSI instead of SUPI in the Bootstrap Request. In addition to SUPI (or IMSI), IMEI, and PSK, you may also include the IP address assigned to the IoT device 10 after SIM authentication.

[0077] The device management device 200 has information pre-stored as device management information 203, such as the information shown in Figure 5. Specifically, the device management device 200 stores the SUPI, IMEI, PSK, and terminal type for each IoT device under management as device management information 203. Note that "terminal type" is an example of device information about an IoT device that is stored together with SUPI, IMEI, and PSK. "Terminal type" may also be called "type". Alternatively, in device management information 203, "IMEI" may be considered as information indicating the terminal type, and the device management information 203 may not have a "terminal type" field.

[0078] The "Terminal Type" is information indicating what kind of device the IoT device 10 is (e.g., AGV, surveillance camera). The "Terminal Type" may also be information indicating the application installed on the IoT device 10. In either case, the "Terminal Type" will determine the server to which the IoT device 10 should connect.

[0079] Note that storing SUPI, IMEI, PSK, and terminal type as device management information 203 is just one example. Additional information other than these may also be stored as device management information 203.

[0080] Hereafter, SUPI, IMEI, and PSK will be collectively referred to as authentication key information. In other words, "SUPI + IMEI + PSK" will be referred to as authentication key information. Note that "SUPI + IMEI" corresponds to the ID of IoT device 10, and "PSK" corresponds to the password of IoT device 10.

[0081] Upon receiving a Bootstrap Request, the LwM2M Bootstrap201 compares the authentication key information received via the Bootstrap Request with the authentication key information held by the device management device 200. If the LwM2M Bootstrap201 confirms that the device management device 200 holds the same authentication key information as the authentication key information received via the Bootstrap Request, it considers the Bootstrap Request to be a valid request from the IoT device 10 and returns LwM2M Server information to the LwM2M client 11 in S4. In S5, the LwM2M Bootstrap201 sends Bootstrap-Finish to the LwM2M client 11.

[0082] Furthermore, the authenticity of the IoT device 10 can be verified by comparing the authentication key information received in S3 with the authentication key information held by the device management device 200; therefore, this comparison process may be called "device authentication."

[0083] The LwM2M Server information includes information that identifies the LwM2M server 202. In S6, the LwM2M client 11 makes a connection request to the LwM2M server 202 of the device management device 200 based on the LwM2M Server information.

[0084] The LwM2M server 202 compares the L2M2M Server information received by the IoT device 10 with its own information. Once the validity of the information received by the IoT device 10 is confirmed, a certificate-based DTLS handshake is performed between the LwM2M client 11 and the LwM2M server 202 in S7. This establishes a DTLS connection between the LwM2M client 11 and the LwM2M server 202. The following S8 takes place within this DTLS connection.

[0085] In S8, the LwM2M client 11 sends a Register (which may also be called a registration request) to the LwM2M server 202. In the example in Figure 4, the Register includes the SUPI, IMEI, and PSK.

[0086] Note that using SUPI, IMEI, and PSK as information to include in Register is just one example. IMSI may be included in Register instead of SUPI. Furthermore, in addition to SUPI (or IMSI), IMEI, and PSK, the IP address assigned to the IoT device 10 after SIM authentication may also be included.

[0087] Upon receiving the Register, the LwM2M server 202 compares the authentication key information received by the Register with the authentication key information held by the device management device 200. If the LwM2M server 202 confirms that the device management device 200 holds the same authentication key information as the authentication key information received by the Register, it determines that the authenticity of the IoT device 202 has been verified. This process of verifying authenticity may also be called "device authentication".

[0088] If device authentication is successful here, for example, the device management device 200 will send routing information to the core network device 100 based on the "terminal type" of the IoT device 10 read from the device management information 203, so that the IoT device 10 can connect to the target server.

[0089] More specifically, for example, the device management device 200 transmits the identification information of the IoT device 10 (e.g., SUPI, IMSI) and the identification information of the destination server (e.g., video storage server, AGV control server) determined from the terminal type of the IoT device 10 (e.g., IMEI) (e.g., IP address) to the core network device 100 (which includes the functions of the routing instruction device 500) as routing control information. The core network device 100 sets up a communication path (logical path) between the IoT device 10 and the transfer device (UPF) connected to the destination server.

[0090] (Example of device configuration) Figure 6 shows an example of the configuration of the core network device 100 in this embodiment. As shown in Figure 6, the core network device 100 includes an authentication unit 110, a route control unit 120, and a data storage unit 130. The data storage unit 130 stores user information, including the unique ID of each user's (each IoT device's) SIM.

[0091] The authentication unit 110 performs SIM authentication using the unique ID of the SIM received from the IoT device 10 and the unique ID of the SIM stored in the data storage unit 130.

[0092] The route control unit 120 performs route setting and other operations based, for example, on route control information received from the device management device 200. The route control unit 120 may also include the functions of the route instruction device 500.

[0093] Figure 7 shows an example of the configuration of the device management device 200 in this embodiment. As shown in Figure 7, the device management device 200 includes an authentication unit 210, a routing control instruction unit 220, and a data storage unit 230. The data storage unit 230 stores the device management information 203 and the like mentioned above. The authentication unit 210 performs device authentication using the device management protocol.

[0094] If the authentication unit 210 successfully authenticates the device, the routing instruction unit 220 transmits routing information, etc., to, for example, the routing instruction device 500 (or the core network device 100).

[0095] Figure 8 shows an example configuration of the IoT device 10 in this embodiment. As shown in Figure 8, the IoT device 10 includes a SIM 11, a communication unit 12, and a data storage unit 13. The communication unit 12 connects to a network such as a mobile network (e.g., 5G, LTE) and communicates with a server, etc. The communication unit 12 also includes the functionality of a client for a device management protocol. The data storage unit 13 stores the IMEI, etc.

[0096] (Example of device hardware configuration) Both the IoT device 10 and the device management device 200 can be implemented, for example, by having one or more computers run programs. The computer used for the device management device 200 may be a physical machine or a virtual machine on the cloud. Hereinafter, the IoT device 10 and the device management device 200 will be collectively referred to as "devices".

[0097] Figure 9 shows an example of the hardware configuration of the computer in this embodiment. Note that if the computer is a virtual machine, the hardware configuration is a virtual hardware configuration. The computer in Figure 9 has a drive device 1000, an auxiliary storage device 1002, a memory device 1003, a CPU 1004, an interface device 1005, a display device 1006, an input device 1007, an output device 1008, etc., all of which are interconnected by bus B.

[0098] The program that enables processing on the computer is provided, for example, on a recording medium 1001 such as a CD-ROM or memory card. When the recording medium 1001 containing the program is set in the drive device 1000, the program is installed from the recording medium 1001 to the auxiliary storage device 1002 via the drive device 1000. However, the program does not necessarily have to be installed from the recording medium 1001; it may also be downloaded from another computer via a network. The auxiliary storage device 1002 stores the installed program as well as necessary files and data.

[0099] The memory device 1003 reads and stores a program from the auxiliary storage device 1002 when a program startup command is received. The CPU 1004 implements the functions related to the memory device 1003 according to the program stored in the memory device 1003. The interface device 1005 is used as an interface for connecting to a network. The display device 1006 displays a GUI (Graphical User Interface) or the like, run by a program. The input device 1007 consists of a keyboard and mouse, buttons, or a touch panel, and is used to input various operation commands. The output device 1008 outputs the calculation results. Note that the device may not include one, more, or all of the display device 1006, input device 1007, and output device 1008.

[0100] (Effects of the embodiment) According to the technology of this embodiment described above, the IoT device can access the legitimate network path only when a combination of a legitimate SIM and a legitimate IoT device is used. Conversely, if a malicious act is committed to replace the SIM with an unauthorized one or IoT device, the device will not be able to connect to the legitimate network path, thus preventing malicious attacks and information leakage to other servers.

[0101] In other words, the technology according to this embodiment utilizes a robust device authentication mechanism based on a device management protocol to detect fraudulent impersonation of IoT devices, such as SIM swapping, on the network side. This allows IoT devices whose authenticity cannot be guaranteed to be kept in a quarantine network or connected terminals to be forcibly isolated from the network. This reliably prevents unauthorized connections to important internal networks by end users.

[0102] Furthermore, by identifying IoT devices that have requested a connection on the network side based on SIM information and device information, it becomes possible to automatically control the network path, thereby reducing the burden on administrators or operators.

[0103] Furthermore, a logical path, such as a GTP tunnel or GRE tunnel, is established between the route-controlled connected terminal and the server, preventing highly confidential and important information from leaking through other communication channels.

[0104] Furthermore, by utilizing standard protocols used in device management within the device authentication mechanism, it becomes possible to monitor and manage IoT devices (e.g., device information such as serial number and signal strength, remote program execution, FOTA, etc.), thereby preventing a wider range of potential security risks.

[0105] Furthermore, by using technologies such as 5G, it is possible to determine which wireless base station a connected IoT device is located under. In addition, by utilizing identifiers such as TAC and TAI assigned to wireless base stations, it is possible to limit the areas where IoT devices are allowed to connect, thereby restricting the use of IoT devices in unintended locations.

[0106] (Note) This specification discloses at least the following routing systems, device management devices, routing methods, and programs. (Additional note 1) A first authentication unit performs first authentication regarding the device using the unique ID of the SIM installed in the device subject to route control, A second authentication unit performs a second authentication of the device using a device management protocol, If the first authentication is successful, the route control unit connects the device to the second authentication unit via the first route, and if the second authentication by the second authentication unit is successful, the route control unit connects the device to the target server via the second route. A route control system equipped with the following features. (Additional note 2) The second authentication unit receives the unique ID of the SIM and the unique ID of the device hardware from the device based on the device management protocol, and performs the second authentication using the unique ID of the SIM and the unique ID of the device hardware. The routing control system described in Appendix 1. (Additional note 3) An authentication unit receives the unique ID of the SIM and the unique ID of the device's hardware from the device that has successfully performed SIM authentication using the unique ID of the SIM installed in the device, based on the device management protocol, and performs authentication of the device using the unique ID of the SIM and the unique ID of the device's hardware. If the authentication unit successfully authenticates the device, the routing instruction unit instructs the core network device or routing instruction device to perform routing to connect the device to the target server. A device management device equipped with the following features. (Additional note 4) The routing instruction unit obtains the type of the device from the device management information held in the device management device, and instructs the core network device or the routing instruction device to perform routing to connect the device to the server corresponding to that type. The device management device described in Appendix 3. (Additional note 5) A routing method performed in a routing system including a first authentication unit and a second authentication unit, The first authentication step involves the first authentication unit performing a first authentication on the device using the unique ID of the SIM installed in the device subject to route control, If the first authentication is successful, the device is connected to the second authentication unit via the first path, and the second authentication unit performs a second authentication of the device using a device management protocol in a second authentication step. If the second authentication by the second authentication unit is successful, a routing control step is taken to connect the device to the target server via the second route. A route control method comprising the following: (Additional note 6) A program for causing a computer to function as a component in the device management device described in Appendix 3 or 4.

[0107] Although this embodiment has been described above, the present invention is not limited to this specific embodiment, and various modifications and changes are possible within the scope of the gist of the invention as described in the claims. [Explanation of symbols]

[0108] 10 IoT devices 11 SIM 12 Communications Department 13 Data Storage Unit 21 Route Control Unit 22 First Certification Department 23 Second Certification Department 100 Core Network Devices 110 Authentication Department 120 Route control unit 130 Data storage unit 200 Device Management Devices 210 Authentication Department 220 Route control instruction unit 230 Data storage unit 300 AGV control server 400 Video Storage Servers 500 Route Indicator 1000 drive unit 1001 Recording media 1002 Auxiliary storage 1003 Memory device 1004 CPU 1005 Interface device 1006 Display device 1007 Input device 1008 Output device

Claims

1. A first authentication unit performs a first authentication for the device using the unique ID of the SIM installed in the device subject to route control, A second authentication unit performs a second authentication of the device using a device management protocol based on LwM2M, A routing control system comprising: a routing control unit that, upon success in the first authentication, connects the device to the second authentication unit via a first route; and upon success in the second authentication by the second authentication unit, connects the device to the target server via a second route; The second authentication unit receives authentication key information, which includes the unique ID of the SIM, the unique ID of the device's hardware, and a pre-shared key pre-configured on the device, as an LwM2M Bootstrap request from the device, and performs the second authentication by comparing the authentication key information with the authentication key information pre-held as device management information. Route control system.

2. A routing method performed in a routing system including a first authentication unit and a second authentication unit, The first authentication step involves the first authentication unit performing a first authentication regarding the device using the unique ID of the SIM installed in the device subject to route control, If the first authentication is successful, the device is connected to the second authentication unit via the first path, and the second authentication unit performs a second authentication of the device using a device management protocol based on LwM2M in the second authentication step. A routing method comprising: a routing control step of connecting the device to the target server via a second route when the second authentication by the second authentication unit is successful, The second authentication unit receives authentication key information, which includes the unique ID of the SIM, the unique ID of the device's hardware, and a pre-shared key pre-configured on the device, as an LwM2M Bootstrap request from the device, and performs the second authentication by comparing the authentication key information with the authentication key information pre-held as device management information. Route control method.

Images