JP7559344B2 - Authorization-based resource access control system, secure component, device, and authorization-based resource access control method - Google Patents

Description

The present invention relates to an authorization-based resource access control system, a secure component, a device, and an authorization-based resource access control method.

Many web services follow the standard established by the IETF (Internet Engineering Task Force) as OAuth 2.0. With such web services, authentication by a specific service provider is the basis for authorization to log in to other services and API integration between services, allowing for smooth service integration. Authentication identifies an entity as a specific entity, and authorization grants access and other rights to the authenticated entity.

In IoT systems, as in Web services, authentication (e.g., authentication of an IoT device) and authorization (e.g., API integration with an IoT device) are often performed at separate times. Also, in IoT systems, there are situations where the authenticators and authorizers are not necessarily all on a public network, as in applications running on a device. For this reason, IoT systems have security issues compared to cases where all integrated services are on a public network, such as Web services.

Therefore, a system has been disclosed in which, in accordance with OAuth 2.0, a client (an application running on a client terminal) uses a pre-stored secret (authorization code) to request the issuance of an access token from an authorization server (token endpoint), receives the access token issued by the authorization server, and uses the access token to obtain resources, for an application running on a device (see Patent Document 1).

JP 2018-84979 A

However, in a system such as that described in Patent Document 1, since the access token is stored on the client terminal, there is a security risk due to the leaking of the access token. In other words, unlike Web services, when OAuth 2.0 is used only by applications on an IoT device, the access token must be stored on the IoT device, but if it is leaked, there is a risk that a third party may be allowed to access unauthorized resources. In addition, due to the nature of IoT systems being operational over long periods of time, once users log in, they often continue to be logged in, making it difficult to set a work time for invalidating the access token. Furthermore, frequent updates of access tokens lead to an increase and concentration of communication traffic, which is a weakness of IoT systems.

The present invention has been made in consideration of the above circumstances, and aims to provide an authorization-based resource access control system, a secure component, a device, and an authorization-based resource access control method that can safely protect issued access tokens for a long period of time.

The authorization-based resource access control system according to an embodiment of the present invention includes an authorization server that authorizes access to resources based on a user authentication result, a resource server having resources whose access is controlled based on the authorization result of the authorization server, and a device on which a client operates. The device includes a secure component that stores token information issued by a specific server and acquired by the client as a result of the authorization server authorizing access to the resource. The client transmits the token information stored in the secure component to the resource server, and the resource server controls the client's access to the resource based on the verification result of the token information.

A secure component according to an embodiment of the present invention is a secure component implemented in a device on which a client operates, which acquires and stores token information issued by a specific server from the client as a result of an authorization server authorizing access to a resource based on a user authentication result, and outputs the stored token information to the client in order to transmit the stored token information to a resource server having a resource whose access is controlled based on the authorization result of the authorization server.

A device according to an embodiment of the present invention includes the above-mentioned secure components and runs a client.

The resource access control method based on authorization according to an embodiment of the present invention is a resource access control method based on authorization for a system including an authorization server that authorizes access to resources based on a user authentication result, a resource server having resources whose access is controlled based on the authorization result of the authorization server, and a device on which a client operates, in which the device stores token information issued by a specified server and acquired by the client as a result of the authorization server authorizing access to the resource in a secure component, the client transmits the token information stored in the secure component to the resource server, and the resource server controls the client's access to the resource based on the verification result of the token information.

The present invention makes it possible to reduce the risk of continuing to hold valid tokens (security risks such as leakage) during long-term operation of a device, while reducing the communication traffic required for re-authentication and token updates.

1 is a schematic diagram showing an example of a configuration of an authorization-based resource access control system according to an embodiment of the present invention; FIG. 11 is an explanatory diagram showing an example of a flow when acquiring a token based on RFC8252. FIG. 11 is an explanatory diagram showing an example of a flow when a token is obtained in an authorization-based resource access control system. FIG. 11 is an explanatory diagram showing an example of internal validation of a token. FIG. 13 is an explanatory diagram showing an example of protection by adding a tamper detection code. FIG. 11 is an explanatory diagram showing an example of protection by token encryption. FIG. 11 is an explanatory diagram showing an example of authentication for a client application. FIG. 11 is an explanatory diagram showing an example of external management using a secure communication path.

The present invention will be described below with reference to the drawings showing an embodiment of the present invention. FIG. 1 is a schematic diagram showing an example of the configuration of an authorization-based resource access control system according to this embodiment. The authorization-based resource access control system includes an IoT device 100 as a device, an authorization server 200, and a token server 400. The authorization-based resource access control system may further include a resource server 300 and a secure component management server 500. In the example of FIG. 1, the authorization server 200 and the token server 400 are configured as separate servers, but the authorization server 200 and the token server 400 may be integrated into a single server.

The IoT device 100 is a device to be implemented, and includes, for example, an embedded board on which an RTOS (Real Time Operating System) or Linux (registered trademark) runs. The IoT device is, for example, a device (also called an electronic device) that is equipped with an OS and can operate independently, and corresponds to a "thing" in the "Internet of Things" (IoT). The IoT device 100 has an SoC (System on Chip) (not shown) and a secure component 50 inside. The IoT device 100 is a device that has the secure component 50 built in and runs a client application (also called a client) 20 that uses resources. Details of the IoT device 100 will be described later.

The device administrator is the administrator of the IoT device 100, has access rights to the IoT device 100, and is the entity (user) that performs user registration with the business providing the resources and performs authentication with the business providing the resources (corresponding to the Resource Owner). The device administrator is a user who expects to realize the desired functions by executing the client application 20 on the IoT device 100. The user is registered on the authorization server 200.

The authorization server 200 is a server for authenticating individual users and then authorizing access to resources 301 held by the resource server 300 based on the permission of the user. The authorization server 200 holds an authorization code 201. The authorization code 201 is a code that is dynamically generated when authentication and authorization are performed by the device administrator, and can basically be a one-time disposable code. Here, "authentication" refers to identifying a certain user as a specific user, and in this embodiment, authentication is performed using a username and password, but the authentication method is not limited to this. Also, "authorization" refers to granting authority such as access to the authenticated user.

The resource server 300 is a server that holds resources 301. The resources 301 are resources that the client application 20 needs to access, and include, for example, data such as files, or, other than data, functions such as API execution (e.g., API for deep learning, etc.).

The token server 400 is a server for issuing tokens (also called access tokens) based on the authorization of the authorization server 200. In this specification, token information means a token, but may also include information related to the token or information accompanying the token. Details of the token server 400 will be described later.

The secure component management server 500 can be intended for remote management of the secure component 50. The secure component management server 500 can communicate with the secure component 50 in the IoT device 100 (e.g., via a secret communication path) and update the functions and status inside the secure component 50.

Which company operates each server illustrated in FIG. 1 varies depending on the individual business case. In this embodiment, the authorization server 200 and resource server 300 are operated by a service provider, and the token server 400 and secure component management server 500 are operated by the manufacturer of the secure component 50, but this is not limited to the above.

In addition to the secure component 50, the IoT device 100 includes a client application 20, a client application certificate 21, and a browser 10.

The client application 20 is an application that realizes functions by accessing resources after obtaining authorization from the business providing the resources. The client application 20 is an application developed by an entity (such as a vendor) other than the business providing the resources.

The client application certificate 21 is a code signing certificate for the client application 20. The code signing certificate is an electronic signature certificate that digitally signs the client application 20 (for example, a private key signature is applied to the hash value of the client application 20), and can authenticate the distributor of the client application 20 and guarantee that it has not been spoofed or its contents have not been tampered with.

The browser 10 is a web browser and is provided as a separate application from the client application 20.

The secure component 50 is a secure execution environment having storage (memory) that is logically or physically isolated from the normal program execution environment that exists within the IoT device 100. In this embodiment, the secure component 50 is mainly assumed to be a secure element (also referred to as SE). The secure element can be configured with a security chip that is tamper-resistant. This allows the issued token information to be safely protected for a long period of time, as described below. In addition, there is no need to frequently update the token information, nor is there a need to set an operation time for invalidating the token information.

The secure component 50 may be a trusted execution environment (also called a TEE). The trusted execution environment refers to an area (so-called TEE: Trusted Execution Environment) partitioned within a system on a chip (SoC) by using, for example, a technology called CPU virtualization support technology (e.g., TrustZone (registered trademark)) on the SoC, and is an area that is more secure than a normal execution environment (also called REE: Rich Execution Environment).

The communication path between the client application 20 and the secure component 50 varies depending on the type of the secure component 50. The communication between the client application 20 and the secure element can use, for example, a serial communication path such as ISO7816/SPI/I2C, and the communication between the client application 20 and the TEE can be performed, for example, via APII/F.

The secure component 50 incorporates an SE (TEE) ID 51, a counter 52, a token 53, a token generation function 60, a token signature verification function 61, a token encryption function 62, a token MAC assignment function 63, a client verification function 64, a secret communication path opening function 65, a token signature verification key (public key) 71, a token encryption key 72, a token MAC key 73, and a client verification key (public key) 74.

The SE(TEE) ID 51 is an ID for uniquely identifying the secure component 50. The SE(TEE) ID 51 stands for SEID 51 or TEEID 51.

The counter 52 counts the number of times the secure component 50 generates a token.

The token 53 is secret information that proves that the resource server 300 has been authorized to access the resource 301. The token 53 can be received from the token server 400 via the client application 20. The data structure and contents of the token 53 differ depending on the individual embodiments described below.

The token generation function 60 is a function executed when the secure component 50 itself generates a token. The token generation function 60 performs processing such as adding the value of the SE (TEE) ID 51 and the counter 52 to the token (also called the initial token) to generate a dynamic token.

The token signature verification function 61 is a function that verifies the signature when a signature is attached to the token received from the token server 400 via the client application 20.

The token encryption function 62 is a function that performs encryption when an encrypted token is exchanged.

The token MAC assignment function 63 is a function executed when assigning a MAC (Message Authentication Code) to a token.

The client verification function 64 is a function executed to perform client authentication when exchanging a token with the client application 20.

The secret communication path opening function 65 is a function that opens a secret communication path with the secure component management server 500, and is assumed to be a communication function such as TLS (Transport Layer Security).

The token signature verification key (public key) 71 is a key used to verify the signature if one is attached to the received token.

The token encryption key 72 is the key used to encrypt the token when sending the encrypted token.

The token MAC key 73 is a key used to calculate the MAC to be assigned to the token.

The client verification key (public key) 74 is a key used to verify the client certificate when performing client authentication.

The token server 400 has an SE (TEE) ID 401, a counter 402, a token 403, a token validity confirmation function 410, a token signature generation function 411, a token decryption function 412, a token MAC verification function 413, a token signature generation key (secret key) 420, a token decryption key 421, and a token MAC verification key 422.

The SE(TEE) ID 401 is an ID for uniquely identifying the secure component 50 in the IoT device 100 to which the token output by the token server 400 is to be output. The SE(TEE) ID 401 means SEID 401 or TEE ID 401.

The counter 402 is a counter that counts the number of times a token is generated when the secure component 50 generates a token. The counter 402 is synchronized with the number of times a token is received from the secure component 50.

The token 403 is secret information that proves that authorization has been granted for the resource 301. The token 403 is dynamically generated in response to the presentation of an appropriate authorization code from the client application 20.

The token validity confirmation function 410 is a function that confirms the validity of the dynamic token generated by the secure component 50. The token validity confirmation function 410 confirms the validity of the token by referring to the values of the SE (TEE) ID 401 and the counter 402.

The token signature generation function 411 is a function that generates a signature for a token and assigns it to the token.

The token decryption function 412 is a function that decrypts an encrypted token when it is received.

The token MAC verification function 413 is a function that verifies the MAC assigned to the token.

The token signature generation key (private key) 420 is a key that generates a signature for the token.

The token decryption key 421 is a key used to decrypt an encrypted token when it is received.

The token MAC verification key 422 is a key used to verify the MAC assigned to the token.

When the secure component 50 dynamically generates a token, the token server 400 records a list of SE (TEE) IDs 401 that can generate tokens and the number of times that the SE (TEE) ID 401 has generated a token. The manufacturer of the secure component 50 is already in charge of managing the IDs of each individual component, making it relatively easy to manage, so it is preferable that the token server 400 be operated by the manufacturer of the secure component 50 or an operator that has a collaborative relationship with the manufacturer. The operator that operates the token server 400 may also be a service operator.

Next, the processing of the resource access control system based on authorization in this embodiment will be described. When an application running on a device (including, for example, the IoT device 100) uses OAuth 2.0, the Internet Engineering Task Force (IETF) defines an authorization flow based on RFC 8252. Therefore, RFC 8252 can be said to be the best practice when a native application uses OAuth 2.0. This is because OAuth 2.0 specifies the procedure for authorization by implicit ground, but implicit ground is not recommended in RFC 8252. Therefore, first, the authorization flow based on RFC 8252 will be described assuming that the client application 20 of the IoT device 100 is a native application.

Figure 2 is an explanatory diagram showing an example of the flow when acquiring a token based on RFC8252, and Figure 3 is an explanatory diagram showing an example of the flow when acquiring a token in an authorization-based resource access control system. Both Figures 2 and 3 follow the authorization flow based on RFC8252. The symbols P1 to P16 shown in Figure 2 correspond to the symbols P1 to P16 shown in Figure 3. The processes indicated by the symbols P1 to P16 are explained below.

P1 (executing client application): The device administrator executes the client application 20.

P2 (Open browser): The client application 20 includes in the request a redirect URI (Uniform Resource Identifier) for returning an authorization code, and opens the authorization page of the authorization server 200 in the browser 10. The redirect URI is a location to which the authorization server 200 transitions (redirects) the browser 10 to another location when the client application 20 is approved and an authorization code is granted. Here, the redirect URI is a URI that indicates the client application 20 itself within the IoT device 100.

P3 (transfer of authorization page): The browser 10 includes in the request a redirect URI for returning the authorization code, and opens the authorization page of the authorization server 200.

P4 (authentication request): The authorization server 200 verifies that the redirect URI included in the request is a valid value that has been preregistered, and then requests user authentication from the device administrator. Here, it requests the input of a user ID and password. Note that user authentication is not limited to the input of a user ID and password, and may involve the input of biometric information, for example.

P5 (Authentication Information Input and Authorization): The device administrator inputs user authentication information to the authorization server 200 to complete authentication. After completing authentication, the device administrator allows the authorization server 200 to allow the client application 20 to access resources. The authorization server 200 verifies the user's authorization and then generates an authorization code for token generation.

P6 (Perform redirection with authorization code): The authorization server 200 returns the redirection URI together with the authorization code to the browser 10 and performs the redirection.

P7 (obtaining authorization code): When the browser 10 opens the redirect URI together with the authorization code, requests to that URI are accepted by the client application 20. Here, the client application 20 obtains the authorization code from the browser 10.

P8 (presentation of authorization code): The client application 20 accesses the token server 400 and presents the authorization code.

P9 (Verify authorization code): The token server 400 checks whether the authorization code presented by the client application 20 is valid. If the check fails, the process is interrupted.

P10 (obtaining token): If the match is successful, the token server 400 generates a new token and returns the generated token to the client application 20.

P11 (saving token): The client application 20 writes the token to the secure component 50.

P12 (token acquisition request): When using the resource 301, the client application 20 requests the secure component 50 to acquire a token.

P13 (obtaining token): The secure component 50 returns the stored token to the client application 20.

P14 (Access to resource (with token)): The client application 20 attaches the token obtained from the secure component 50 and requests the resource server 300 to access the resource 301.

P15 (token verification): The resource server 300 verifies the validity of the token received from the client application 20 with the token server 400. If the token is not valid, it denies access from the client application 20 and ends the process.

P16 (Provision of resource): If the token is valid, the resource server 300 provides the client application 20 with access to the resource 301.

As described above, the client application 20 stores the token obtained from the token server 400 in the secure component 50. This reduces the risk (e.g., security risk such as leakage) of continuing to hold a valid token obtained from a specific server (e.g., the token server 400) during long-term operation of the IoT device 100, while reducing the communication traffic required for re-authentication and token renewal. In addition, because the token is stored securely, there is no need to frequently refresh the token to avoid leakage, etc., and there is no need to set a work time for invalidating the token.

By implementing the same token verification logic as the token server 400 in the secure component 50, when the token is stored in the secure component 50, it is possible to check whether the token has a valid value (whether it is an inappropriate token) and prevent tampering with the token. Below, a case where a public key signature is used as the verification algorithm is described. Note that the verification algorithm is not limited to a public key signature, and other verification methods may be used.

Figure 4 is an explanatory diagram showing an example of internal token verification. The processes indicated by symbols P21 to P32 are explained below.

P21 (execute client application): The device administrator executes the client application 20.

P22 (Open browser): The client application 20 includes in the request a redirect URI for returning an authorization code, and opens the authorization page of the authorization server 200 in the browser 10. Here, the redirect URI is a URI that indicates the client application 20 itself within the IoT device 100.

P23 (Transfer of authorization page): The browser 10 includes in the request a redirect URI for returning the authorization code, and opens the authorization page of the authorization server 200.

P24 (Authentication request): The authorization server 200 verifies that the redirect URI included in the request is a valid pre-registered value, and then requests user authentication from the device administrator.

P25 (Authentication information input and authorization): The device administrator inputs user authentication information to the authorization server 200 to complete authentication. After completing authentication, the device administrator allows the authorization server 200 to allow the client application 20 to access resources. The authorization server 200 verifies the user's authorization and then generates an authorization code for token generation.

P26 (Perform redirection with authorization code): The authorization server 200 returns the redirection URI together with the authorization code to the browser 10 and performs the redirection.

P27 (obtaining authorization code): When the browser 10 opens the redirect URI together with the authorization code, requests to that URI are accepted by the client application 20. At this point, the client application 20 obtains the authorization code from the browser 10.

P28 (presentation of authorization code): The client application 20 accesses the token server 400 and presents the authorization code.

P29 (Confirmation of authorization code): The token server 400 verifies whether the authorization code presented by the client application 20 is valid. If the verification fails, the process is interrupted here.

P30 (token acquisition): If the match is successful, the token server 400 generates a new token. At this time, the token server 400 calls the token signature generation function 411, signs the token using the token signature generation key (private key) 420 that it holds, and returns the token to the client application 20.

P31 (token verification): The client application 20 instructs the secure component 50 to write a token. At this time, prior to writing the token, the secure component 50 calls the token signature verification function 61 and verifies the signature attached to the token using the token signature verification key (public key) 71, thereby verifying the validity of the token. If the verification fails, the process ends here and the token is not saved.

P32 (save token): If the verification is successful, the secure component 50 saves the token. The process from P32 onwards is similar to the process from P11 onwards shown in FIG. 3, but when the resource server 300 checks the validity of the token received from the client application 20, it may verify the token using a token signature verification key, similar to the process of P31.

As described above, when the secure component 50 stores a token, it is possible to prevent token tampering, such as a token replacement attack by inserting an unauthorized token, by checking the validity of the token.

In the above example, the token is stored in the secure component 50, but the secure component 50 may dynamically generate a token. In the following, protection by adding a tamper detection code to the token and protection by cryptographic technology will be described. First, protection by dynamically generating a token and adding a tamper detection code will be described.

Figure 5 is an explanatory diagram showing an example of protection by adding a tamper detection code. The processes indicated by symbols P41 to P58 are explained below.

P41 (executing client application): The device administrator executes the client application 20.

P42 (Open browser): The client application 20 includes in the request a redirect URI for returning an authorization code, and opens the authorization page of the authorization server 200 in the browser 10. Here, the redirect URI is a URI that indicates the client application 20 itself within the IoT device 100.

P43 (Transfer of authorization page): The browser 10 includes in the request a redirect URI for returning the authorization code, and opens the authorization page of the authorization server 200.

P44 (Authentication request): The authorization server 200 verifies that the redirect URI included in the request is a valid value that has been preregistered, and then requests user authentication from the device administrator. Here, it requests the input of a user ID and password.

P45 (Authentication information input and authorization): The device administrator inputs user authentication information to the authorization server 200 to complete authentication. After completing authentication, the device administrator allows the authorization server 200 to allow the client application 20 to access resources. The authorization server 200 verifies the user's authorization and then generates an authorization code for token generation.

P46 (Perform redirection with authorization code): The authorization server 200 returns the redirection URI together with the authorization code to the browser 10 and performs the redirection.

P47 (obtaining authorization code): When the browser 10 opens the redirect URI together with the authorization code, requests to that URI are accepted by the client application 20. Here, the client application 20 obtains the authorization code from the browser 10.

P48 (presentation of authorization code): The client application 20 accesses the token server 400 and presents the authorization code.

P49 (Verify authorization code): The token server 400 checks whether the authorization code presented by the client application 20 is valid. If the check fails, the process is interrupted here.

P50 (token acquisition): If the match is successful, the token server 400 generates a new initial token and returns the generated initial token to the client application 20.

P51 (saving token): The client application 20 writes the initial token to the secure component 50.

P52 (token acquisition request): When using the resource 301, the client application 20 requests the secure component 50 to acquire a token.

P53 (Generating a token with ID and counter): The secure component 50 calls the token generation function 60, adds its own unique ID 51 and the value of the counter 52 that records the number of tokens generated to the initial token, and generates a token with ID and counter. After generating the token, the secure component 50 adds 1 to the value of the counter 52.

P54 (assigning MAC to token): The secure component 50 uses the token MAC key 73 it holds to calculate a MAC (message authentication code) for the token with ID and counter, and assigns the calculated MAC to the token. For the MAC calculation, an existing MAC calculation algorithm (e.g., HMAC-SHA256, etc.) can be used for the token data string.

P55 (Access to resource (with token)): The client application 20 attaches the ID and counter-attached token obtained from the secure component 50 along with the MAC, and requests the resource server 300 to access the resource 301.

P56 (token MAC verification): The resource server 300 requests the token server 400 to verify the ID and counter-attached token received from the client application 20. The token server 400 calls the token MAC verification function 413 and verifies the MAC assigned to the token using the token MAC verification key 422 that it holds. Basically, it derives the MAC by performing the same calculation as the MAC calculation performed by the secure component 50, and compares it with the MAC assigned to the token. If the two do not match, it considers the token to be invalid and ends the process.

P57 (token validity verification): The token server 400 acquires an ID from the token to identify the secure component 50 that sent the token, reads the value of the counter 402 stored corresponding to that ID, and compares it with the counter value embedded in the token acquired from the resource server 300. After completing the comparison, the token server 400 adds 1 to the value of the counter 402. If the ID is not found or the counter values do not match, the token is deemed to be invalid and processing ends here.

P58 (Providing resource): If the token is valid, the resource server 300 provides the client application 20 with access to the resource 301.

As in the above example, the secure component 50 generates a token with an ID and a counter (a new token) using information stored internally and the stored initial token. The information stored internally may be any confidential information for generating a new token, such as a unique ID, a counter value that records the number of times a token has been generated, or a random number element.

The client application 20 sends a new token to the resource server 300. The resource server 300 controls the client application 20's access to the resource 301 based on the verification result of the new token. In other words, if the verification is successful, the client application 20 can access the resource 301. In this way, by dynamically generating a token on the client side and verifying the token on the resource server 300, it is possible to prevent token reuse (replay attack using a token) and spoofing, etc.

In addition, as described above, by assigning a tamper detection code (in the above example, a MAC) to the token, an attacker who does not know the private key cannot calculate the tamper detection code and cannot generate a token and MAC that are treated properly by the token verification side. This makes it possible to prevent token forgery and tampering.

In the above example, tamper detection is performed by adding a MAC using a keyed hash, but the algorithm for tamper detection is not limited to the above example, and any algorithm can be used as needed.

Next, we'll explain how tokens are dynamically generated and protected by encryption.

Figure 6 is an explanatory diagram showing an example of protection by token encryption. The processes indicated by symbols P61 to P78 are explained below.

P61 (executing client application): The device administrator executes the client application 20.

P62 (Open browser): The client application 20 includes in the request a redirect URI for returning an authorization code, and opens the authorization page of the authorization server 200 in the browser 10. Here, the redirect URI is a URI that indicates the client application 20 itself within the IoT device 100.

P63 (Transfer of authorization page): The browser 10 includes in the request a redirect URI for returning the authorization code, and opens the authorization page of the authorization server 200.

P64 (Authentication request): The authorization server 200 verifies that the redirect URI included in the request is a valid value that has been preregistered, and then requests user authentication from the device administrator. Here, the user is requested to enter a user ID and password.

P65 (Authentication information input and authorization): The device administrator inputs user authentication information to the authorization server 200 to complete authentication. After completing authentication, the device administrator allows the authorization server 200 to allow the client application 20 to access resources. The authorization server 200 verifies the user's authorization and then generates an authorization code for token generation.

P66 (Perform redirection with authorization code): The authorization server 200 returns the redirection URI together with the authorization code to the browser 10 and performs the redirection.

P67 (obtaining authorization code): When the browser 10 opens the redirect URI together with the authorization code, requests to that URI are accepted by the client application 20. Here, the client application 20 obtains the authorization code from the browser 10.

P68 (presentation of authorization code): The client application 20 accesses the token server 400 and presents the authorization code.

P69 (Verify authorization code): The token server 400 checks whether the authorization code presented by the client application 20 is valid. If the check fails, the process is interrupted here.

P70 (token acquisition): If the match is successful, the token server 400 generates a new initial token and returns the generated initial token to the client application 20.

P71 (saving token): The client application 20 writes the initial token to the secure component 50.

P72 (token acquisition request): When using the resource 301, the client application 20 requests the secure component 50 to acquire a token.

P73 (Generating a token with ID and counter): The secure component 50 calls the token generation function 60, adds its own unique ID 51 and the value of the counter 52 that records the number of tokens generated to the initial token, and generates a token with ID and counter. After generating the token, the secure component 50 adds 1 to the value of the counter 52.

P74 (token encryption): The secure component 50 calls the token encryption function 62 and encrypts the ID and counter-attached token using the token encryption key 72 held by the secure component 50. The encryption algorithm used may be either asymmetric key encryption (e.g., RSA) or symmetric key encryption (common key encryption) (e.g., AES: Advanced Encryption Standard). In this embodiment, encryption is performed with AES using a common key.

P75 (Access to resource (with token)): The client application 20 requests access to the resource 301 from the resource server 300, attaching the encrypted token obtained from the secure component 50.

P76 (token decryption): The resource server 300 requests the token server 400 to verify the encrypted token received from the client application 20. The token server 400 calls the token decryption function 412, decrypts the encrypted token using the token decryption key 421 that it holds, and obtains a token with an ID and a counter.

P77 (token validity verification): The token server 400 acquires an ID from the token to identify the secure component 50 that sent the token, reads the value of the counter 402 stored corresponding to the ID, and compares it with the counter value embedded in the token acquired from the resource server 300. After completing the comparison, the token server 400 adds 1 to the value of the counter 402. If the ID is not found or the counter values do not match, the token is deemed to be invalid and processing ends here.

P78 (Providing resource): If the token is valid, the resource server 300 provides the client application 20 with access to the resource 301.

In the above example, as in the case of FIG. 5, the secure component 50 generates a token with an ID and counter (a new token) using information held internally and the stored initial token. In other words, instead of continuing to use a token with a fixed value issued by the token server 400, the secure component 50 and the token server 400 separately hold a key and information about the state of the secure component 50 (e.g., ID, counter), and then verify the validity of the token by verifying the consistency of both parties using a key.

In conventional technologies such as OAuth 2.0, it is technically difficult to prevent unauthorized access when a token is stolen, so alternative measures include shortening the token's validity period, invalidating the token, and verifying the signature, but all of these measures increase the communication load on the client side.

On the other hand, in the case of this embodiment, as described above, the ID of the secure component 50 side is attached to the token, so that the legitimacy of the token sender can be verified. Also, by attaching a counter to the token, it is possible to prevent the token from being reused. Furthermore, since the token is encrypted, it is difficult to forge or decipher. This allows the IoT device 100 to communicate only with the resource server 300 without performing additional communication such as refreshing the token, and thus allows optimal communication while maintaining security.

The method of token encryption and decryption and the method of validity verification (ID
and a counter) are just an example, and any appropriate method can be used as the algorithm and verification policy for token generation and validity verification.

Although storing the token in the secure component 50 reduces the risk of direct exploitation as in normal file storage, there is still a risk that a fraudulent application posing as the client application 20 may read the token from the secure component 50 and exploit it. In this case, token exploitation can be prevented by storing a common key between the client application 20 and the secure component 50 and opening a secure channel between the client application 20 and the secure component 50. Furthermore, a method of verifying the client application 20 by presenting a client certificate will be described below.

Figure 7 is an explanatory diagram showing an example of authentication for a client application. The processes indicated by symbols P81 to P98 are explained below.

P81 (executing client application): The device administrator executes the client application 20.

P82 (Open browser): The client application 20 includes in the request a redirect URI for returning an authorization code, and opens the authorization page of the authorization server 200 in the browser 10. Here, the redirect URI is a URI that indicates the client application 20 itself within the IoT device 100.

P83 (Transfer of authorization page): The browser 10 includes in the request a redirect URI for returning the authorization code, and opens the authorization page of the authorization server 200.

P84 (Authentication request): The authorization server 200 verifies that the redirect URI included in the request is a valid pre-registered value, and then requests user authentication from the device administrator.

P85 (Authentication information input and authorization): The device administrator inputs user authentication information to the authorization server 200 to complete authentication. After completing authentication, the device administrator allows the authorization server 200 to allow the client application 20 to access resources. The authorization server 200 verifies the user's authorization and then generates an authorization code for token generation.

P86 (Perform redirection with authorization code): The authorization server 200 returns the redirection URI together with the authorization code to the browser 10 and performs the redirection.

P87 (Obtaining authorization code): When the browser 10 opens the redirect URI together with the authorization code, requests to that URI are accepted by the client application 20. Here, the client application 20 obtains the authorization code from the browser 10.

P88 (presentation of authorization code): The client application 20 accesses the token server 400 and presents the authorization code.

P89 (Confirmation of authorization code): The token server 400 verifies whether the authorization code presented by the client application 20 is valid. If the verification fails, the process is interrupted here.

P90 (obtaining token): If the match is successful, the token server 400 generates a new token and returns the generated token to the client application 20.

P91 (sending client application certificate): The client application 20 sends the client application certificate 21 to the secure component 50 prior to writing the token.

P92 (Verifying client application certificate): The secure component 50 calls the client verification function 64 and verifies the transmitted client application certificate 21 using the client verification key (public key) 74 that it holds. Specifically, the secure component 50 calculates a hash value of the client application 20, compares the calculated hash value with the value obtained by decrypting the encrypted hash value included in the client application certificate 21, and confirms that they match. If they do not match, the client application 20 is considered to be an unauthorized client application, and the process ends here.

P93 (saving token): If the verification of the client application certificate is successful, the client application 20 writes the token to the secure component 50. The secure component 50 confirms that the verification of the client application certificate is complete, and then saves the token internally.

P94 (token acquisition request): When using the resource 301, the client application 20 requests the secure component 50 to acquire a token. At this time, the client application certificate verification performed in P92 is performed again.

P95 (obtaining token): If the verification of the client application certificate is successful, the secure component 50 returns the stored token to the client application 20.

P96 (Access to resource (with token)): The client application 20 attaches the token obtained from the secure component 50 and requests the resource server 300 to access the resource 301.

P97 (Token Verification): The resource server 300 verifies the validity of the token received from the client application 20 with the token server 400. If the token is not valid, it denies access from the client application 20 and ends the process.

P98 (Providing resource): If the token is valid, the resource server 300 provides the client application 20 with access to the resource 301.

The above-described embodiment can prevent unauthorized configuration and exploitation of tokens by unauthorized apps.

The client verification key (public key) 74 is stored in advance in the secure component 50, and general users cannot change the client verification key (public key) 74. In addition, in order to prevent replay attacks, it is preferable that the hash value of the client application 20 is calculated directly by the secure component 50 itself. Note that client authentication using the client application certificate 21 is just one example, and is not limited to this, and any other method may be used for client authentication.

As described above, by incorporating a secure component 50 on the IoT device 100 side, it is possible to utilize an authorization mechanism while maintaining appropriate security on the IoT device 100. On the other hand, in order to maintain the security of the IoT device 100, it is desirable to appropriately maintain and manage the internal state of the keys and each function held inside, and to update the internal state as necessary. The following describes how to update the internal state of the IoT device 100.

Figure 8 is an explanatory diagram showing an example of external management using a secret communication channel. The processes indicated by symbols P101 to P106 are explained below.

P101 (Powering on IoT device): The device administrator powers on IoT device 100 in order to use it.

P102 (state check instruction to secure component): When the IoT device 100 is powered on, it issues a state check instruction to the secure component 50 to see if an internal state needs to be updated.

P103 (calling the secret communication channel establishment function): Upon receiving the status check instruction, the secure component 50 calls its own internal secret communication channel establishment function 65.

P104 (Establishment of a secret communication path): The secret communication path establishment function 65 establishes a secret communication path to the secure component management server 500. Here, TLS (Transport Layer Security) communication is assumed, but a secure channel using another communication protocol may be used. If the secure component 50 does not have its own network communication function, the communication function of the IoT device 100 may be used. However, the endpoint of the secret communication path is always between the secure component 50 and the secure component management server 500.

P105 (Preparation of content to be updated): The secure component management server 500 prepares the content to be updated in response to the establishment of a secret communication path. In this embodiment, for example, a new key is updated in preparation for the token encryption key being compromised. Note that the update target is not limited to the token encryption key. The secure component management server 500 generates and prepares the key to be updated.

P106 (sending content): The secure component management server 500 sends content to the secure component 50 via a secret communication path. Here, the secure component management server 500 sends the token encryption key 72 to the secure component 50. If the opposing content exists on another server, as in this embodiment, a separate secret communication path can be opened to that server to perform the update. Here, a secret communication path is opened to the token server 400, and the token decryption key 421 is updated at the same time.

This allows the functionality or state of the token of the secure component 50 to be updated remotely, thereby maintaining the security of the IoT device 100.

In the above embodiment, key updating is exemplified, but the update target is not limited to keys, and any content held by the secure component 50 can be updated. For example, if the secure component 50 is a secure element that supports the Java Card (trademark) platform, and various processes (encryption process, generation process, signature verification process, etc.) are implemented as Java Card applets, various functions can be updated by updating the applet. In addition, in the case of an embodiment in which a flag is provided for switching between enabling and disabling functions related to the token, the authorization function can be remotely enabled and disabled by updating the flag via a secret communication path. In addition, in this embodiment, in order to ensure updating, power-on is used as a trigger for remote management, but this is not limited thereto, and other actions such as the startup of a client application or the operation of another application on the IoT device may be used as the trigger.

The authorization-based resource access control system of this embodiment includes an authorization server that authorizes access to resources based on a user authentication result, a resource server having resources whose access is controlled based on the authorization result of the authorization server, and a device on which a client operates. The device includes a secure component that stores token information issued by a specified server and acquired by the client as a result of the authorization server authorizing access to the resource. The client transmits the token information stored in the secure component to the resource server, and the resource server controls the client's access to the resource based on the verification result of the token information.

The secure component of this embodiment is a secure component implemented in a device on which a client operates, and acquires and stores token information issued by a specific server from the client as a result of an authorization server authorizing access to a resource based on a user authentication result, and outputs the stored token information to the client in order to transmit the stored token information to a resource server having a resource whose access is controlled based on the authorization result of the authorization server.

The device of this embodiment is equipped with the above-mentioned secure components and runs a client.

The resource access control method based on authorization in this embodiment is a resource access control method based on authorization for a system including an authorization server that authorizes access to resources based on a user authentication result, a resource server having resources whose access is controlled based on the authorization result of the authorization server, and a device on which a client operates, in which the device stores token information issued by a specified server and acquired by the client as a result of the authorization server authorizing access to the resource in a secure component, the client transmits the token information stored in the secure component to the resource server, and the resource server controls the client's access to the resource based on the verification result of the token information.

The authorization server authorizes access to resources based on the user authentication result. The resource server has resources whose access is controlled based on the authorization result of the authorization server. The device (also called an IoT device) runs a client (client application). The device has a secure component that stores token information issued by a specific server and obtained by the client as a result of the authorization server authorizing access to the resource.

That is, the client obtains token information issued by a specific server and stores the obtained token information in a secure component within the device. This reduces the risk (e.g., security risks such as leakage) of continuing to hold valid token information obtained from a specific server (e.g., a token server) during long-term operation of the device, while reducing the communication traffic required for re-authentication and updating of token information.

The client sends the token information stored in the secure component to the resource server. The resource server controls the client's access to resources based on the results of verifying the token information. In other words, if the verification is successful, the client can access the resources. This makes it possible to realize an authorization-based resource access control system that can safely protect issued token information for a long period of time.

In the authorization-based resource access control system of this embodiment, the secure component is a trusted execution environment or a secure element.

The secure component in this embodiment is a trusted execution environment or a secure element.

The secure component is a trusted execution environment or a secure element. The trusted execution environment refers to an area (so-called TEE: Trusted Execution Environment) divided within a SoC (System on Chip) by using, for example, a technology called CPU virtualization support technology (for example, TrustZone (registered trademark)) on the SoC, and is a more secure area than the normal execution environment (also called REE: Rich Execution Environment). The secure element can be composed of a security chip with tamper resistance. This allows the issued token information to be safely protected for a long period of time. In addition, there is no need to frequently update the token information, nor is there a need to set an operation time for invalidating the token information.

In the authorization-based resource access control system of this embodiment, the secure component has a token verification function that verifies the validity of the token information acquired by the client, and stores the token information if the verification is successful.

The secure component of this embodiment has a token verification function that verifies the validity of the token information obtained from the client, and if the verification is successful, stores the token information.

The secure component verifies the validity of the token information acquired by the client, and if the verification is successful, stores the token information. In other words, when the secure component stores the token information, it checks the validity of the token information. This makes it possible to prevent tampering with the token information, such as a token information replacement attack by inserting unauthorized token information.

In the authorization-based resource access control system of this embodiment, the secure component has a token generation function that generates new token information using information held internally and stored token information, the client transmits the new token information to the resource server, and the resource server controls the client's access to resources based on the verification results of the new token information.

The secure component of this embodiment has a token generation function that generates new token information using internally held information and stored token information, and outputs the new token information to the client in order to send the new token information to the resource server.

The secure component generates new token information using information held internally and stored token information. The information held internally may be any confidential information for generating new token information, such as a unique ID, a counter value that records the number of times token information has been generated, or a random number element.

The client sends new token information to the resource server. The resource server controls the client's access to resources based on the results of verifying the new token information. In other words, if the verification is successful, the client can access the resources. In this way, by dynamically generating token information on the client side and verifying that token information on the resource server, it is possible to prevent the reuse of token information (replay attacks using token information) and spoofing.

In the authorization-based resource access control system of this embodiment, the secure component has a detection code generation function that generates a tamper detection code using a key held internally, the client adds the tamper detection code to the new token information and transmits it to the resource server, and the resource server controls the client's access to resources based on the verification result of the tamper detection code.

The secure component of this embodiment has a detection code generation function that generates a tamper detection code using an internally held key, and outputs the new token information with the tamper detection code added to the client in order to transmit the new token information with the tamper detection code added to the resource server.

The secure component generates a tamper detection code using a key held internally. The client adds the tamper detection code to the new token information and sends it to the resource server. The resource server controls the client's access to resources based on the results of verifying the tamper detection code. In other words, if the verification is successful, the client can access the resource.

By assigning a tamper detection code, an attacker who does not know the key (private key) held inside the secure component cannot calculate the tamper detection code, and the token information verification side cannot verify the tamper detection code. This makes it possible to prevent forgery or tampering of token information.

In the authorization-based resource access control system of this embodiment, the secure component has a token encryption function that encrypts the new token information using an encryption key stored internally, the client transmits the encrypted token information to the resource server, and the resource server controls the client's access to resources based on the verification result of the new token information obtained by decrypting the encrypted token information.

The secure component of this embodiment has a token encryption function that encrypts the new token information using an encryption key stored internally, and outputs the encrypted token information to the client in order to send the encrypted token information to the resource server.

The secure component encrypts the new token information using an encryption key stored internally. The client sends the encrypted token information to the resource server. The resource server controls the client's access to resources based on the verification results of the new token information obtained by decrypting the encrypted token information. In other words, the secure component and the resource server hold opposing keys, and dynamically generated token information is protected by applying encryption technology.

Since the token information is encrypted, it is difficult to forge or decrypt, eliminating the risk of an attacker understanding the structure of the token information and preventing unauthorized use of resources by tampering with the token information.

In the authorization-based resource access control system of this embodiment, the secure component has a client authentication function that authenticates the client, and determines whether or not to exchange the token information with the client depending on the authentication result of the client.

The secure component of this embodiment has a client authentication function that authenticates the client, and determines whether or not to exchange the token information with the client depending on the authentication result of the client.

The secure component authenticates the client and, depending on the result of the client authentication, determines whether or not to exchange token information with the client. That is, when a client stores token information in the secure component, or when a client retrieves token information from the secure component, the secure component authenticates the requesting client (application). This makes it possible to prevent unauthorized applications from unauthorized setting or exploiting token information.

In the authorization-based resource access control system of this embodiment, the secure component has an opening function for opening a secret communication path with an external server, and at least a portion of the internal functions of the secure component and the information or keys held internally by the secure component can be updated from the external server.

The secure component of this embodiment has an opening function for opening a secret communication path with an external server, and at least a portion of the internal functions of the secure component and the information or keys held internally by the secure component can be updated from the external server.

The secure component has an opening function for opening a secret communication path between the secure component and an external server. At least a portion of the internal functions of the secure component and the information or keys held internally by the secure component can be updated from an external server. In other words, the internal state of the secure component can be changed via the secret communication path opened by the secure component. This allows the functions or state related to the token information of the secure component to be updated remotely, thereby maintaining the security of the device.

10 Browser 20 Client application 21 Client application certificate 50 Secure component 51 SE (TEE) ID
52 Counter 53 Token 60 Token generation function 61 Token signature verification function 62 Token encryption function 63 Token MAC assignment function 64 Client verification function 65 Secret communication path opening function 71 Token signature verification key (public key)
72 Token encryption key 73 Token MAC key 74 Client verification key (public key)
100 IoT device 200 Authorization server 201 Authorization code 300 Resource server 301 Resource 400 Token server 401 SE (TEE) ID
402 Counter 403 Token 410 Token validity confirmation function 411 Token signature generation function 412 Token decryption function 413 Token MAC verification function 420 Token signature generation key (secret key)
421 Token decryption key 422 Token MAC verification key 500 Secure component management server

Claims (18)

an authorization server that authorizes access to resources based on a user authentication result;
a resource server having a resource whose access is controlled based on an authorization result of the authorization server;
A device on which a client runs;
The device comprises:
a secure component that stores token information issued by a predetermined server and acquired by the client as a result of the authorization server authorizing access to a resource;
The client:
Sending the token information stored in the secure component to the resource server;
The resource server comprises:
Verifying the validity of token information issued by the predetermined server, and controlling access to resources of the client based on a result of the verification of the token information ;
The secure component comprises:
A token verification function is provided for verifying the validity of the token information acquired by the client,
If the verification is successful, store the token information.
An authorization-based resource access control system. an authorization server that authorizes access to resources based on a user authentication result;
a resource server having a resource whose access is controlled based on an authorization result of the authorization server;
The device on which the client runs
Equipped with
The device comprises:
a secure component that stores token information issued by a predetermined server and acquired by the client as a result of the authorization server authorizing access to a resource;
The client:
Sending the token information stored in the secure component to the resource server;
The resource server comprises:
Verifying the validity of token information issued by the predetermined server, and controlling access to resources of the client based on a result of the verification of the token information;
The secure component comprises:
A client authentication function for authenticating the client is provided,
determining whether or not to exchange the token information with the client depending on the authentication result of the client;
An authorization-based resource access control system. The secure component comprises:
A trusted execution environment or secure element,
3. The authorization-based resource access control system according to claim 1 or 2 . The secure component comprises:
A token verification function is provided for verifying the validity of the token information acquired by the client,
If the verification is successful, store the token information.
The authorization-based resource access control system according to claim 2. The secure component comprises:
A token generation function is provided for generating new token information using internally held information and stored token information,
The client:
Sending the new token information to the resource server;
The resource server,
and controlling access to resources of the client based on a result of verifying the new token information.
The authorization-based resource access control system according to any one of claims 1 to 4 . The secure component comprises:
Equipped with a detection code generation function that generates a tamper detection code using an internally held key,
The client:
Adding the tamper detection code to the new token information and transmitting the new token information to the resource server;
The resource server comprises:
controlling access to resources of the client based on a verification result of the tamper detection code;
The authorization-based resource access control system according to claim 5 . The secure component comprises:
a token encryption function for encrypting the new token information using an encryption key stored therein;
The client:
Sending the encrypted token information to the resource server;
The resource server comprises:
and controlling access to resources of the client based on a verification result of the new token information obtained by decrypting the encrypted token information.
The authorization-based resource access control system according to claim 5 . The secure component comprises:
A client authentication function for authenticating the client is provided,
determining whether or not to exchange the token information with the client depending on the authentication result of the client;
The authorization-based resource access control system according to claim 1 . The secure component comprises:
Equipped with a function to open a secret communication channel with an external server,
At least a part of the internal functions of the secure component and the information or keys held internally by the secure component can be updated from the external server;
The authorization-based resource access control system according to any one of claims 1 to 8 . A secure component implemented on a device on which a client operates, comprising:
an authorization server obtains token information issued by a predetermined server as a result of authorizing access to a resource based on a user authentication result from the client and stores the token information;
outputting the stored token information to the client in order to transmit the stored token information to a resource server that has a resource to which access is controlled based on the authorization result of the authorization server, verifies the validity of token information issued by the predetermined server, and controls access to the resource of the client based on the verification result of the token information;
A token verification function is provided for verifying the validity of token information acquired from the client,
If the verification is successful, store the token information .
Secure components. The secure component comprises:
A trusted execution environment or secure element,
The secure component of claim 10 . A token generation function is provided for generating new token information using internally held information and stored token information,
outputting the new token information to the client for transmission to the resource server;
A secure component according to claim 10 or claim 11. Equipped with a detection code generation function that generates a tamper detection code using an internally held key,
outputting the new token information to which the tampering detection code has been added to the client in order to transmit the new token information to which the tampering detection code has been added to the resource server;
The secure component of claim 12. a token encryption function for encrypting the new token information using an encryption key stored therein;
outputting the encrypted token information to the client for transmission to the resource server;
The secure component of claim 12. A client authentication function for authenticating the client is provided,
determining whether or not to exchange the token information with the client depending on the authentication result of the client;
A secure component according to any one of claims 10 to 14. Equipped with a function to open a secret communication channel with an external server,
At least a part of the internal functions of the secure component and the information or keys held internally by the secure component can be updated from the external server;
A secure component according to any one of claims 10 to 15. A client operates comprising a secure component according to any one of claims 10 to 16.
device. an authorization server that authorizes access to resources based on a user authentication result;
a resource server having a resource whose access is controlled based on an authorization result of the authorization server;
A method for controlling resource access based on authorization in a system comprising:
The device comprises:
storing token information issued by a predetermined server, which is acquired by the client as a result of the authorization server authorizing access to a resource, in a secure component;
The secure component comprises:
Verifying the validity of the token information acquired by the client;
If the verification is successful, storing the token information;
The client:
Sending the token information stored in the secure component to the resource server;
The resource server,
verifying the validity of token information issued by the predetermined server, and controlling access to resources of the client based on a result of verifying the token information;
A method for controlling resource access based on authorization.

Images