Apparatus and method for mediating authentication information configuration - Patents.com

JP7631284B2Active Publication Date: 2025-02-18SORACOM INC
View PDF 7 Cites 0 Cited by

Patent Information

Application Number
JP2022186982
Authority / Receiving Office
JP · JP
Patent Type
Patents
Current Assignee / Owner
Filing Date
2022-11-23
Publication Date
2025-02-18
Estimated Expiration
2038-07-03

Smart Images

  • Figure 0007631284000001
    Figure 0007631284000001
  • Figure 0007631284000002
    Figure 0007631284000002
  • Figure 0007631284000003
    Figure 0007631284000003
Patent Text Reader

Abstract

Facilitates the configuration of authentication information for services provided over IP networks. [Solution] In a situation where there is no authentication information shared between an IoT device and a service provider device for a service used by the IoT device, an intermediary device is used to mediate between them, capable of authenticating legitimate access between the two. As an example, an encryption key CK stored in the intermediary device and the IoT device as a result of SIM authentication of the SIM held by the IoT device is used as a master key for the IoT device to use each service. Then, the intermediary device and the IoT device generate application keys specific to the service used by the IoT device based on the master key, and send them to the service provider device from the intermediary device via a secure connection, thereby setting a common key as authentication information for the IoT device and the service provider device. The SIM authentication process for generating an encryption key can prevent attacks against the SQN using fraudulent requests.
Need to check novelty before this filing date? Find Prior Art

Description

[Technical field]

[0001] The present invention relates to an apparatus and method for mediating the setting of authentication information, and more particularly to an apparatus and method for mediating the setting of authentication information for services provided on an IP network. [Background technology]

[0002] With the advancement of sensing and communication technologies, the number of devices connected to computer networks is increasing, and the idea of ​​the Internet of Things, in which all things are networked, is becoming more widespread. In the following, devices that can be connected directly or indirectly to IP networks, not limited to the Internet, are referred to as "IoT devices."

[0003] Services for IoT devices are being researched and developed every day, but in order to use these services, it is necessary to securely embed authentication information specific to each service into each IoT device in a way that cannot be stolen from the outside. Summary of the Invention [Problem to be solved by the invention]

[0004] However, implementing secure embedding of authentication information is not easy because it complicates the design and manufacturing process of IoT devices and increases costs. It is said that the number of things connected to the Internet will be 20 billion to 100 billion by 2020, and the more the number of devices increases explosively, the more explosive the costs will be.

[0005] The present invention has been made in consideration of these problems, and its first object is to provide an apparatus, a method, and a program therefor that facilitate setting authentication information for services provided on an IP network.

[0006] A second object of the present invention is to provide a SIM authentication process that can be used in the above-mentioned device, method, and program therefor. [Means for solving the problem]

[0007] In order to achieve this object, a first aspect of the present invention is an intermediary device that constitutes a system comprising a service provider device that provides a service on an IP network, an IoT device that uses the service, and an intermediary device that mediates the setting of authentication information for a connection between the IoT device and the service provider device, the intermediary device receiving initial setting information including a key Id and a signature calculated based on a first key, which is an encryption key or a key corresponding thereto that is generated during an authentication process of a SIM held by the IoT device and stored together with a key Id in the IoT device and the intermediary device, verifying the signature based on the first key that can be obtained by the key Id, calculating a second key based on the first key and a nonce, and transmitting the second key to the service provider device as the authentication information.

[0008] Moreover, a second aspect of the present invention is characterized in that, in the first aspect, the initial setting information is received from the service provider device which has received an initial setting request including the initial setting information from the IoT device.

[0009] A third aspect of the present invention is characterized in that in the first or second aspect, the service provider device has credentials for connecting to the intermediate device.

[0010] Furthermore, a fourth aspect of the present invention is characterized in that in the third aspect, before transmitting the second key, authentication of the service provider device is performed using the credential.

[0011] A fifth aspect of the present invention, in any one of the first to fourth aspects, is characterized in that the nonce is generated by the intervening device.

[0012] A sixth aspect of the present invention, in any one of the first to fifth aspects, is characterized in that the intermediate device exists within a core network of a cellular network that can be connected by the SIM.

[0013] Furthermore, a seventh aspect of the present invention is characterized in that, in the sixth aspect, the intervening device has secret information identical to the secret information stored in the SIM, and the encryption key is calculated based on the secret information during an authentication process of the SIM.

[0014] Furthermore, an eighth aspect of the present invention is characterized in that, in any one of the first to seventh aspects, during the authentication process of the SIM, resynchronization of the SIM and the SQN stored in the intervening device is performed based on an AUTS generated by the SIM.

[0015] In addition, a ninth aspect of the present invention is a method in an intermediate device that constitutes a system including a service provider device that provides a service on an IP network, an IoT device that uses the service, and an intermediate device that mediates the setting of authentication information for a connection between the IoT device and the service provider device, characterized in that it includes a step of receiving initial setting information including a key Id and a signature calculated based on a first key, the first key being an encryption key or a key corresponding thereto that is generated in an authentication process of a SIM held by the IoT device and stored together with a key Id in the IoT device and the intermediate device, a step of verifying the signature based on the first key that can be obtained by the key Id, a step of calculating a second key based on the first key and a nonce, and a step of transmitting the second key to the service provider device as the authentication information.

[0016] In addition, a tenth aspect of the present invention is a program for causing a computer to execute a method in an intermediary device that constitutes a system including a service provider device that provides a service on an IP network, an IoT device that uses the service, and an intermediary device that mediates the setting of authentication information for a connection between the IoT device and the service provider device, the method being characterized in that it includes a step of receiving initial setting information including a key Id and a signature calculated based on a first key, the first key being an encryption key or a key corresponding thereto that is generated in an authentication process of a SIM held by the IoT device and stored together with a key Id in the IoT device and the intermediary device, a step of verifying the signature based on the first key that can be obtained by the key Id, a step of calculating a second key based on the first key and a nonce, and a step of transmitting the second key to the service provider device as the authentication information. Effect of the Invention

[0017] According to one aspect of the present invention, by applying an authentication process of a SIM possessed by an IoT device, even if the IoT device is not able to share authentication information with a service provider device when the device is shipped from the factory, it becomes easy to do so later. [Brief description of the drawings]

[0018] [Figure 1] FIG. 2 is a diagram illustrating a device that mediates the setting of authentication information for a service provided on an IP network according to a first embodiment of the present invention. [Diagram 2] FIG. 2 is a diagram illustrating an overview of a method for mediating setting of authentication information according to the first embodiment of the present invention. [Diagram 3] FIG. 4 is a diagram illustrating an example of a method for mediating setting of authentication information according to the first embodiment of the present invention. [Figure 4] FIG. 11 is a diagram for explaining a SIM authentication process according to the second embodiment of the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0019] Hereinafter, an embodiment of the present invention will be described in detail with reference to the drawings.

[0020] (First embodiment) 1 shows a device that mediates the setting of authentication information for a service provided on an IP network according to a first embodiment of the present invention. The device 100 can communicate with an IoT device 110 over other computer networks including not only a cellular network but also an IP network, and can also communicate with a service provider device 120 that provides a service used by the IoT device 110 over an IP network. The overall picture of the system includes the service provider device 120 that provides a service on an IP network, the IoT device 110 that uses the service, and the device 100 that mediates the setting of authentication information for a connection between the IoT device 110 and the service provider device 120.

[0021] The IoT device 110 has a SIM 110-1 for connecting to a cellular network, and the SIM 110-1 stores an identification number such as an IMSI and secret information such as a K value. In this embodiment, the SIM 110-1 is provided by the operator of the device 100 or its affiliated company, and the identification number and secret information are also stored in the device 100 or a storage medium or storage device accessible from the device 100. The device 100 verifies the reliability of the IoT device 110 through a SIM authentication process using the identification number and secret information. The SIM authentication can be performed in the same manner as a conventional process using HLR / HSS by the MILENAGE algorithm or the like, but has some unique features of the present invention. This point will be described later in a second embodiment.

[0022] Furthermore, the service provider device 120 has credentials for communication with the device 100 based on the trust that the operator of the device 100 has established with the service provider by some method. Here, "credentials" is a general term for information used for authentication, including IDs and passwords. The service provider can safely share credentials with the operator of the device 100 by a known method, but there is a risk of leakage between the service provider and the IoT device 110 during the manufacture of each IoT device 110, and in order to minimize this risk, an increase in costs cannot be avoided.

[0023] In the present invention, in a situation where there is no authentication information shared between an IoT device 110 and a service provider device 120, by using a device 100 that can authenticate between the two devices for legitimate access as an intermediary device, it becomes possible to easily set authentication information remotely, accelerating the practical spread of IoT systems.

[0024] More specifically, in this embodiment, a cipher key CK or a key corresponding thereto stored in the device 100 and the IoT device 110 as a result of SIM authentication is used as a master key (parent key) for the IoT device 110 to use various services. Then, in the device 100 and the IoT device 110, an application key (a key with a specific purpose) specific to a service used by the IoT device 110 is generated based on the master key, and the application key is transmitted from the device 100 to the service provider device 120 via a secure connection, so that a common key can be set as authentication information for the IoT device 110 and the service provider device 120.

[0025] In this embodiment, the encryption key CK is used as an example for explanation, but it is also possible to use an integrity key IK stored in the apparatus 100 and the IoT device 110 as a result of SIM authentication or a key corresponding thereto as the master key. In this specification, the integrity key can be positioned as an example of a key corresponding to the encryption key.

[0026] Device 100 exists within the core network of a cellular network and can be a communication device of an MNO (mobile network operator), or can be a communication device of an MVNO (mobile virtual network operator) that is connected to the communication infrastructure of an MNO to provide wireless communication services, and SIM 110-1 can be a SIM card provided by the MNO or MVNO.

[0027] Between the MNO and the MVNO, there may be an MVNE (Mobile Virtual Network Provider) that provides support services for the MVNO to smoothly carry out its business, and the MVNE may have a communication infrastructure for connecting to the MNO's communication infrastructure to provide wireless communication services. In this case, the device 100 may be a communication device of the MVNE, and the SIM 110-1 may be a SIM card provided by the MVNE.

[0028] Also, all or part of the device 100 may be an instance on a cloud, or on a public cloud or a private cloud. Here, in this specification, "cloud" refers to a system that can dynamically provision and provide computing resources such as CPU, memory, storage, and network bandwidth on a network according to demand. For example, a cloud can be used by AWS or the like. Also, "public cloud" refers to a cloud that can be used by multiple tenants.

[0029] The SIM 110-1 possessed by the IoT device 110 can be a physical SIM card, but it can also be a semiconductor chip (also called an "eSIM") embedded in the IoT device 110, or it is also possible for software to be mounted in a secure area within the module of the IoT device 110 and for an identification number and confidential information to be stored in the software; there are various possible ways in which the IoT device 110 can hold the values ​​and programs required for SIM authentication.

[0030] 2 shows an overview of a method for mediating the setting of authentication information according to this embodiment. First, the IoT device 110 transmits a bootstrap request (initial setting request) to the service provider device 120 (not shown). The initial setting to be performed includes setting an application key for using the service in the IoT device 110 and the service provider device 120, and may further include setting connection information required for the IoT device 110 to connect when using the service.

[0031] A bootstrap request can be sent by installing a bootstrap agent in the IoT device 110 as software or a program for this purpose, and having the agent start up when the IoT device 110 is turned on for the first time, or by having the agent send the request in response to the expiration of authentication information that is set as described below.

[0032] The destination of the initial setting request can be specified directly or indirectly by an administrator of the IoT device 110 via a user console of the intermediary device 100, for example, by installing one or more pieces of client software for services available on the IoT device 110 in the IoT device 110 and storing the destination within the software, by storing a list of one or more destinations of the initial setting request for services available on the IoT device 110, or by the administrator of the IoT device 110. The bootstrap agent and the client software do not necessarily have to be separate programs, but in this embodiment, the bootstrap agent is capable of obtaining the destination of the initial setting request.

[0033] The initial setting request includes a key ID for identifying a master key (also called a "first key") as initial setting information, and a signature based on the master key and a timestamp that is added as necessary is added. If a timestamp is used to generate the signature, the initial setting information will also include the timestamp. As will be described later, when the generated master key is stored in the apparatus 100 and the IoT device 110 during the SIM authentication process, a key ID can also be generated and stored in association with each other.

[0034] Next, the device 100 receives initial setting information from the service provider device 120 (S201). The device 100 authenticates the service provider device 120 that has transmitted the initial setting information (S202), and if the authentication result is positive, obtains a master key based on the key ID and verifies the signature (S203). The order of authentication of the service provider device 120 and authentication of the signature may be reversed.

[0035] Then, device 100 generates a nonce and calculates an application key (also called a "second key") based on the master key and the nonce (S204). Then, device 100 transmits the application key and the nonce to service provider device 120 (S205). IoT device 110 can receive the nonce from service provider device 120 as described further below and use it to calculate the application key using the same algorithm as device 100, so that IoT device 110 and service provider device 120 can both set a common key as authentication information.

[0036] Here, although nonce generation is performed by the device 100, it is also conceivable to have the service provider device 120 or the IoT device 110 perform the required transmission and reception. If nonce generation is performed by the service provider device 120 or the IoT device 110, it is considered that the management of the intervening device 100 is not necessarily thorough, and there is a risk that a careless nonce will be generated. In that case, although it is desirable to generate different application keys for different services, the same keys may be generated, or an attacker may be able to guess the nonce generation logic.

[0037] The intervening device 100 includes a communication unit 101-1 such as a communication interface, a processing unit 101-2 such as a processor or CPU, and a storage unit 101-3 including a storage device or storage medium such as a memory or a hard disk. The processing unit 101-2 executes a program for performing each of the above-mentioned and below-mentioned processes stored in the storage unit 101-3 or a storage device or storage medium accessible from the intervening device 100, thereby realizing each of the processes described below. As shown in FIG. 1, the intervening device 100 can be separated into a first device 101 and a second device 102 depending on the contents of the processes, but these can also be made into a single device or further separated. Other devices can also be realized by similar hardware. The program executed by each device may include one or more programs, and can be recorded in a computer-readable storage medium to be a non-transient program product.

[0038] Fig. 3 shows a specific example of a method for mediating the setting of authentication information according to the present embodiment. First, the IoT device 110 makes an initial setting request by transmitting initial setting information such as a key ID to a destination of the service provider device 120 specified by "example.com / v1 / path / to / something / ". Although Fig. 3 shows parameters such as {keyId}, it does not show all the parameters transmitted and received.

[0039] The service provider device 120 requests the device 100 to generate an application key based on the received initial setting information. In the device 100, although the order is variable, the device 100 verifies the signature included in the initial setting information, authenticates the service provider device 120, and further checks whether the service provider device 120 has access authority to the designated key ID as necessary. The device 100 provides credentials to each service provider, and can set a master key or its ID with which each service provider can provide a service as an access authority. More specifically, it is possible to specify one or a service or a service provider that can access the master key or its key ID generated as a result of the authentication in a SIM authentication request specifying AUTS described in the second embodiment.

[0040] The signature can be, for example, a hash value or digest value of a value obtained by concatenating a master key and a timestamp that is added as necessary, and the same calculation can be performed in the device 100 to verify the signature based on whether the hash value or digest value matches or does not match. SHA-256 can be given as an example of a hash function for obtaining the hash value.

[0041] Then, the device 100 generates a nonce required for calculating the application key. The nonce can be a string of numbers generated from random or pseudorandom numbers, such as [23, 130, 4, 247, ...]. The application key is then calculated using the generated nonce and a master key that can be obtained by the received key Id. As a specific example, the application key can be a hash value of a value obtained by concatenating these values. The application key is transmitted to the service provider device 120 via a secure communication path between the device 100 and the service provider device 120.

[0042] The service provider device 120 sets the received application key as authentication information, and transmits connection information for the IoT device 110 to use the service to the IoT device 110, and the IoT device 110 that receives this performs the required settings. The connection information may include destination information, such as a URL or IP address of the destination. Furthermore, if there is any setting required in the service provider device 120 other than the setting of the application key, this is performed. Furthermore, in this embodiment, the connection information includes the above-mentioned nonce. The IoT device 110 uses the received nonce to calculate an application key that is the same as the application key set in the service provider device 120.

[0043] As an example, when client software for a service to be used is installed in the IoT device 110, connection information for the service may be read by the software, and the IoT device 110 may automatically be able to use the service. In this case, the software is capable of communication using an application key.

[0044] The IoT device 110 can be any device that has the required communication function and can perform SIM authentication and initial setting, and is required to be able to execute software in programming languages ​​such as C and Java (registered trademark). It can also be extended using a different programming language (Ruby, Go, Javascript (registered trademark), etc.) by wrapping the C implementation. For example, it can be a device with an OS such as Linux (registered trademark) or Android (registered trademark) installed.

[0045] Please note that unless the word "only" is used, such as "based only on XX," "in response to XX," or "in the case of XX only," this specification assumes that additional information may also be taken into consideration.

[0046] Also, just to be clear, even if there is an aspect of a method, program, terminal, device, server or system (hereinafter referred to as a "method, etc.") that performs an operation different from that described in this specification, each aspect of the present invention is directed to an operation that is the same as any of the operations described in this specification, and the existence of an operation different from that described in this specification does not make the method, etc. outside the scope of each aspect of the present invention.

[0047] Second Embodiment The SIM authentication of the SIM held by the IoT device 110 by the intervening device 100 described in the first embodiment can be performed in the same manner as the conventional process using HLR / HSS, but it is possible to add the improvements described below.

[0048] 1, the intervening device 100 can be divided into a first device 101 and a second device 102 depending on the processing content, and in this embodiment, the second device 102 is mainly responsible for generating parameters required for SIM authentication. This at least partially corresponds to the function of the AuC of the communication carrier.

[0049] The second device 102 stores an identification number such as an IMSI stored in the SIM 110-1 and secret information such as a K value, and further stores an SQN synchronized between the SIM 110-1 and the second device 102. The SQN is usually incremented synchronously in the SIM and the AuC in response to a SIM authentication request specifying an identification number such as an IMSI.

[0050] Since the generation of the encryption key CK mentioned in the first embodiment can be performed by communication between the IoT device 110 and the intervening device 100 or the second device 102 via a computer network that is not necessarily limited to a cellular network, it is possible that an unauthorized request from a device that does not have a legitimate SIM and has somehow obtained an identification number such as an IMSI may increment the SQN managed by the second device 102, causing a discrepancy with the SQN in the IoT device 110. In this embodiment, attacks against the SQN by such unauthorized requests are suppressed.

[0051] In FIG. 4, the IoT device 110 and the SIM 110-1 of the IoT device 110 are shown as separate elements. This is intended to distinguish between processes performed by executing a program in the IoT device 110 and processes performed inside the SIM 110-1 by the IoT device 110 accessing the SIM 110-1 as being of different natures, but it should be noted that both can be considered as processes performed on the IoT device 110. When the IoT device 110 is the subject, it can also be understood as referring to a program for SIM authentication that runs on the IoT device 110. In addition, in FIG. 4, the second device 102 is shown separately from the first device 101, but it should be noted that this can also be considered as a process performed on the intermediate device 100. In addition, the following description will be given with reference to FIG. 4, but it should be noted that FIG. 4 does not show all parameters transmitted and received.

[0052] First, the IoT device 110 requests an IMSI from the SIM 110-1. The SIM 110-1 returns the IMSI value to the IoT device 110. The IoT device 110 that has received the IMSI requests SIM authentication from the first device 101. The first device 101 requests the second device 102 to generate an authentication vector including AUTN, RAND, CK, IK, and XRES.

[0053] In order to suppress the above-mentioned fraudulent requests, this authentication vector generation request sets the SQN to an invalid value, and the AUTN determined based on the SQN is set to a value that causes SIM authentication to fail. If the value of SQN is set to 0, the SQN will not match if SIM authentication has been performed on SIM 110-1 even once. Also, instead of specifying an invalid value for SQN in the first device 101, it may be specified in the second device 102, or more specifically, a value lower than the correct SQN stored in the second device 102 may be specified. Also, in light of the purpose of this embodiment, it is possible to generate only the AUTN, RAND, etc. required for subsequent processing and return them to the first device 101 without generating the entire authentication vector.

[0054] The first device 101, which has received the authentication vector from the second device 102, transmits the AUTN and RAND to the IoT device 110, and the IoT device 110 passes the AUTN and RAND to the SIM 110-1 and requests key calculation. Since the SQNs do not match, the SIM 110-1 generates an AUTS required for a Resync request to synchronize the SQNs as an error process and passes it to the IoT device 110. The IoT device 110 specifies the IMSI, RAND, and AUTS and requests SIM authentication again from the first device 101. Here, the AUTS is a parameter that cannot be calculated without knowing the secret information stored in the SIM 110-1.

[0055] In response to the designation of AUTS and RAND, the first device 101 sends a Resync request for resynchronization to the second device 102. The second device 102 generates an authentication vector by designating the SQN of SIM 110-1, which is included in the AUTS in a masked form, and returns it to the first device 101. The first device 101 generates a key Id for identifying the received encryption key CK, and stores the two in association with each other. It also stores XRES in association with these.

[0056] The first device 101 transmits the key Id, AUTN, and RAND to the IoT device 110, and the IoT device 110 requests the SIM 110-1 to calculate a key using the AUTN and RAND. The SIM 110-1 calculates CK and RES using the received AUTN and RAND as well as secret information K stored in its own storage medium or storage device, and passes them to the IoT device 110.

[0057] The IoT device 110 transmits the key Id and RES to the first device 101, requesting verification of the generated CK. The first device 101 performs verification by acquiring an XRES based on the key Id and comparing it with the received RES, and if they match, sets a verified flag for the CK identified by the key Id. The first device 101 then transmits a SIM authentication success response to the IoT device 110 together with the expiration date of the CK as necessary, and the IoT device 110 stores the CK in association with the key Id. At this time, the CK may also be stored in association with the IMSI.

[0058] In this embodiment, CK or a key corresponding thereto can be used as a master key for the IoT device 110 to use various services in subsequent processing, thereby making it possible to apply the key agreed upon by SIM authentication without making frequent SIM authentication requests.

[0059] In addition, in the SIM authentication process according to this embodiment, in order to prevent unauthorized SIM authentication requests from devices that do not have a legitimate SIM, SQN synchronization, which is a prerequisite for key calculation, is intentionally made to fail, triggering Resync, which requires secret information that can only be accessed by a legitimate SIM. Then, by executing the subsequent process on the condition that Resync is successful, it is possible to nullify the above-mentioned unauthorized attacks. [Explanation of symbols]

[0060] 100 Intervention device 101 First Device 101-1 Communications Department 101-2 Processing section 101-3 Storage section 102 Second Device 110 IoT devices 110-1 SIM 120 Service Provider Equipment

Claims

1. A system including an IoT device that can use services provided by a plurality of service provider devices on an IP network, and an intermediate device that intermediates setting of authentication information for connection between the IoT device and the service provider devices, The IoT device transmits an initial setting request to a destination of any one of the plurality of service provider devices; The intervening device comprises: Receive initial setting information including a key ID from the destination; Obtaining a first key, which is a key generated in an authentication process of a SIM possessed by the IoT device and stored together with the key Id in the IoT device and the intermediate device, or a key corresponding thereto, by using the key Id; Calculating a second key based on the first key and a nonce; The authentication information, including the second key, is transmitted to the service provider device.

2. The system according to claim 1, The destination is specified by an administrator of the IoT device.

3. The system according to claim 1, The destination is included in a plurality of destinations stored in the IoT device.

4. A system according to any one of claims 1 to 3, The intermediary device transmits the nonce to the service provider device.

5. A system according to any one of claims 1 to 4, The IoT device transmits the initial setting request in response to the expiration of the authentication information.

6. A method in a system including an IoT device that can use services provided by a plurality of service provider devices on an IP network, and an intermediary device that mediates setting of authentication information for a connection between the IoT device and the service provider devices, A step of transmitting an initial setting request to a destination of any one of the plurality of service provider devices by the IoT device; receiving, from the destination, initial configuration information including a key ID by the intervening device; The intermediate device obtains, by using the key Id, a first key, which is generated in an authentication process of a SIM held by the IoT device and stored together with the key Id in the IoT device and the intermediate device, or a key corresponding thereto; the intervening device calculating a second key based on the first key and a nonce; the intermediary device transmitting the authentication information including the second key to the service provider device; Includes.

7. A program for causing a computer to execute a method in a system including an IoT device that can use services provided by a plurality of service provider devices on an IP network, and an intermediary device that mediates setting of authentication information for a connection between the IoT device and the service provider devices, the method comprising: A step of transmitting an initial setting request to a destination of any one of the plurality of service provider devices by the IoT device; receiving, from the destination, initial configuration information including a key ID by the intervening device; The intermediate device obtains, by using the key Id, a first key, which is generated in an authentication process of a SIM held by the IoT device and stored together with the key Id in the IoT device and the intermediate device, or a key corresponding thereto; the intervening device calculating a second key based on the first key and a nonce; the intermediary device transmitting the authentication information including the second key to the service provider device; Includes.

Citation Information

Patent Citations

  • Secret key updating method, device and system

    CN107104932A

  • Communication system, server, communication device, communication method, and program

    JP2018082353A

  • Device and method for mediating setting of authentication information

    JP2020010099A

  • Authentication Method And Related Method For Transmitting Information

    US20070178886A1

  • System and method of using a GAA / GBA architecture as digital signature enabler

    WO2010128348A1