KR101873991B1

KR101873991B1 - Method of delegating access right between IoT devices

Info

Publication number: KR101873991B1
Application number: KR1020170050316A
Authority: KR
Inventors: 김정미; 어성율
Original assignee: (주)케이사인
Priority date: 2017-04-19
Filing date: 2017-04-19
Publication date: 2018-07-04

Abstract

A method of delegating access rights between IoT devices is disclosed. The owner terminal establishes the owner's trusted ownership relationship with the target device. The owner terminal of the owner whose trusted ownership relationship with the target device has been established provides the first user terminal of the first user with access authority to access the resource of the target device. The first use subject terminal requests access to the resource of the target device based on the access right. The target device verifies the access request based on the information on the trusted ownership relationship, and determines whether or not the first use principal terminal permits access to the target device according to the verification result. The owner terminal may provide a first token chain including a first delegation token and a self signed token signed by the owner to the first use subject terminal to enable the first use subject terminal to issue an access token to another use subject terminal have. The target device verifies the access right by submitting the token payload from the terminal making a request for access to its resource, thereby granting or denying the access request.

Description

[0001] The present invention relates to a method of delegating access rights between IoT devices,

The present invention relates to an Internet of Things (IoT), and more particularly to a technology for delegating access to a target device among IoT devices.

With the advent of IoT, many of the devices we use in everyday life are controllable over the network and form part of a larger distributed system. These devices range from tiny embedded devices, wearables, large home appliances and automobiles. In such an IoT environment, devices communicate with each other and satisfy the needs of users. For example, a home-security system intercepts the perimeter of the house interacting with a security camera to protect it from intruders, and the suspicious behavior is recorded on the user's storage server.

Authorization in a distributed system is complicated to manage because resources are distributed across multiple device networks under different management domains. Moreover, it makes certification more difficult because it does not know beforehand between all devices and the subjects that they want to access.

Centralized authorization, on the other hand, handles all access control logic in the cloud or back-end server. The advantage of the central authorization model is that it allows unified management at unified windows for device resources scattered across multiple locations. However, the following main drawbacks exist. There is a possibility of privacy breach due to the risk of exposure of the personal information stored in the center. The service provider has a great deal of burden to securely manage personally identifiable information (PII). There is also a drawback that it relies on Internet connectivity. In other words, the device can not be used in a non-internet environment (eg, on an airplane) because the device must be connected to the Internet for communication. In addition, it is inconvenient to use because it is necessary to build a centralized ID management system.

The present invention is intended to provide a method for delegating an access right to an IoT device which allows a user of the third terminal to access the owner's device by passing the owner information to the third terminal.

The present invention is also intended to provide a delegation method capable of delegating access authority to an IoT device even in an offline environment that can not be connected to the Internet.

The present invention relates to a method and apparatus for allowing an access to an IoT device in an IoT environment to be performed in a peer-to-peer manner rather than a centralized control method in consideration of the dispersibility of IoT devices. To provide a method of delegating device access authority.

According to embodiments of the present invention, a method of delegating access authority between IoT devices is provided. The method comprising: a delegation step of providing an access right of an owner terminal of an owner having a trusted owning relationship to a target device to access a resource of the target device, to the first use subject terminal of the first user; An access step in which the first use-principal terminal makes an access request to the resource of the target device based on the access right; And a verification step of verifying the access request on the basis of the information on the trusted ownership relationship in the target device and determining whether to permit access to the target device of the first use subject terminal according to the verification result do.

In one embodiment of the present invention, the method may further include a step of establishing ownership in which the owner terminal establishes the owner's trusted ownership relationship with the target device, prior to the delegation step.

In one embodiment of the present invention, the ownership establishment step may include: the owner terminal authenticating to the target device, the owner key including the public key of the owner terminal, name, and proof of ownership of the target device Requesting establishment of an ownership relationship while providing information; Verifying the reliability of ownership of the target device of the owner terminal using the ownership authentication information provided by the target device; Storing a public key and a name of an owner of the target device that has passed the verification of trustworthiness of ownership; Providing the owner terminal with resource meta information used by the target device to grant access to its resource; The owner terminal generates a first access token for authenticating the self-signed token signed by the owner and the access right to the resource of the target device, and stores the first access token in a self-signed token store . &Lt; / RTI >

In one embodiment of the present invention, the resource meta information may include at least a name of an accessible resource of the target device, a unique identifier of the resource, and an action list that is an action list that can be taken for the resource.

In one embodiment of the present invention, the self-signed token may include signature information by at least an owner's name, a public key, an expiration date, and an owner's private key.

According to an embodiment of the present invention, the delegation step may include: identifying the first user principal terminal so that the owner terminal delegates access rights to the resource of the target device to the first user principal terminal; The owner terminal requesting the first user's public key to the first user principal terminal; Providing the first user's terminal with the public key of the first user to the owner terminal; The owner terminal may issue a second access token to the first user principal terminal and provide the access right to the first user principal terminal, and the second access token may include at least the first user A public key, a token expiration date, access right information for the resource of the target device, and information signed by the owner's private key.

In one embodiment of the present invention, the step of identifying the first user terminal may include: acquiring an arbitrary temporary value (Nonce) generated by the owner terminal by the first user principal terminal; Returning a response message (ACK) including the nonce acquired by the first user principal terminal to the owner terminal; Verifying whether the nonce returned by the owner terminal is the same as the nonce generated by the owner terminal; And if the user terminal has passed the verification, specifying the first user equipment terminal as the delegated terminal.

In one embodiment of the present invention, the manner in which the first user equipment terminal obtains the Nonce may be a non-communication information transmission method using no communication interface.

In an embodiment of the present invention, the information exchange between the target device, the owner terminal, and the first user principal terminal may be performed by a peer-to-peer communication method other than when the first user principal terminal obtains the Nonce. &Lt; / RTI >

According to an embodiment of the present invention, the delegation step may include a step of, in response to a public key request of a first user, authenticating the public key of the first user using the private key of the first user matching the public key, And providing a proof of position (POP) value to the owner terminal.

In one embodiment of the present invention, the method further comprises: generating the token payload for accessing the resource of the target device by the first user equipment terminal having received the second access token and submitting the token payload to the target device Wherein the token payload comprises a Nonce signed with the private key of the first user and a token chain combining the self-signed token signed by the owner received from the owner terminal and the second access token, Includes signature information by at least the owner's name, public key, expiration date, owner's private key; Verifying the validity of the token payload submitted by the first use subject terminal based on the information on the trusted ownership relationship of the owner; The target device extracts the 'access right information on the resource of the target device' included in the token payload whose validity is verified, stores it in the memory, generates a session ID corresponding to the extracted access right information, Providing a using subject terminal; Providing the target user terminal with an access request message for a desired resource of the target device together with the session ID; The target device compares the access request message received from the first user equipment terminal with the access privilege information corresponding to the session ID stored in the memory to determine whether the access request of the first user equipment terminal Verifying whether the user has authority; And a step of allowing the target device to grant or deny the access request of the first user equipment terminal based on the verification result.

According to an embodiment of the present invention, the delegation step may include generating the first delegation token by the owner terminal, wherein the first delegation token is transmitted to the second usage principal terminal of the second user, To issue a third access token with access rights to the resource of the target device; And providing the token chain including the first delegation token and the self-signed token signed by the owner to the first user principal terminal, wherein the self-signature token includes at least a name of the owner , A public key, an expiration date, and signature information by the owner's private key.

In one embodiment of the present invention, the first delegation token includes at least the name of the delegator, the public key of the delegator, the token expiration date, the ID of the access token bound to the first delegation token, and the value signed by the delegator's private key .

In one embodiment of the present invention, the method may further comprise: the first use-principal terminal, which has received the first delegation token, transmits the second usage token to the second usage- And issuing the third access token having the authority to access the target device to the second usage subject terminal.

In one embodiment of the present invention, the method further comprises: generating the token payload for accessing the resource of the target device by the second use-user terminal having received the third access token and submitting the token payload to the target device Wherein the token payload may include a Nonce signed with the private key of the second user and a chain of delegation tokens received from the first user principal terminal, And the third access token received from the first use subject terminal and the third access token received from the first use subject terminal, wherein the target device can include the self- Validating the token payload; The target device extracts the 'access right information for the resource of the target device' contained in the token payload whose validity is verified, stores it in the memory, generates a session ID corresponding to the extracted access right information, Providing a using subject terminal; Providing the second user principal terminal with an access request message for a desired resource of the target device to the target device together with the session ID; The target device compares the access request message received from the second user equipment terminal with the 'access right information corresponding to the session ID' stored in the memory and transmits an access request of the second user equipment terminal to the desired resource Verifying whether the user has authority; And the step of allowing the target device to grant or deny the access request of the second usage subject terminal based on the verification result.

In an embodiment of the present invention, the range of authority that can be delegated to the first delegation token may be the same as or narrower than the authority information of the second access token, which is an access token bound to the first delegation token .

In one embodiment of the present invention, the method further comprises, when the first delegate token received from the owner terminal further includes a re-delegation authority, And issuing a second delegation token to the second delegatee terminal based on the delegation authority. The second delegation token may further include a second delegation token, the second delegation token being transmitted to the third user's terminal of the third user And a fourth access token having an access right to the resource of the target device.

The present invention has various advantages as follows.

Users can delegate their own access rights to target device resources to other devices / applications / users, etc. (up to multiple levels), which is highly scalable and flexible. In other words, a principal delegated access authority can access and delegate to a principal in the authority granted to him / her. That is, according to the present invention, an owner terminal can delegate authority to access a resource of a target device to a third other terminal. This authorization delegation can be done chained to another user's terminal.

Unlike the centralized approach, the present invention allows anyone to become an authorization server for another Principal (device / user / application).

Since the delegator terminal does not require identification and authentication of the user / device in delegating the access authority to the resource of the target device to the delegator terminal, there is no need for separate ID management.

Since the exchange of information for delegating the access authority can be done in a peer-to-peer manner, the privacy of the concerned party can be guaranteed since there is no need to manage ID-related data in the center.

It is possible to manage the access authorization to the resource of the target device even in an environment in which the Internet is not connected.

1 shows a configuration of a system 10 for off-line delegation of IoT device access rights according to one embodiment of the present invention.
FIG. 2 illustrates an overall service flow of an offline delegation method of an IOT device access right according to an embodiment of the present invention.
Figure 3 illustrates the format of a delegation token.
Figure 4 illustrates the format of an access token.
Figure 5 shows a chain of delegation tokens held in a token chain store and an issued delegation token and an access token.
6 is a diagram for explaining a procedure for verifying validity of a chain hierarchy using a token chain.
FIG. 7 shows a procedure for establishing ownership.
FIG. 8 shows an example of a scenario for delegating access authority to a target device.
FIG. 9 specifically shows a procedure for delegating access authority to a target device.
10 is a flow diagram illustrating the delegation trigger process.
11 shows a request for accessing a resource of a target device of a terminal and a procedure for verifying the request.
Figure 12 shows the token payload creation process in more detail.
13 shows a procedure for verifying the validity of the token payload presented by the using subject terminal in the target device.

For the embodiments of the invention disclosed herein, specific structural and functional descriptions are set forth for the purpose of describing an embodiment of the invention only, and it is to be understood that the embodiments of the invention may be practiced in various forms, The present invention should not be construed as limited to the embodiments described in Figs.

The present invention is capable of various modifications and various forms, and specific embodiments are illustrated in the drawings and described in detail in the text. It is to be understood, however, that the invention is not intended to be limited to the particular forms disclosed, but on the contrary, is intended to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the invention.

The terms first, second, etc. may be used to describe various components, but the components should not be limited by the terms. The terms may be used for the purpose of distinguishing one component from another. For example, without departing from the scope of the present invention, the first component may be referred to as a second component, and similarly, the second component may also be referred to as a first component.

It is to be understood that when an element is referred to as being "connected" or "connected" to another element, it may be directly connected or connected to the other element, . On the other hand, when an element is referred to as being "directly connected" or "directly connected" to another element, it should be understood that there are no other elements in between. Other expressions that describe the relationship between components, such as "between" and "between" or "neighboring to" and "directly adjacent to" should be interpreted as well.

The terminology used in this application is used only to describe a specific embodiment and is not intended to limit the invention. The singular expressions include plural expressions unless the context clearly dictates otherwise. In the present application, the terms "comprises ", or" having ", and the like, are used to specify the presence of stated features, integers, But do not preclude the presence or addition of steps, operations, elements, parts, or combinations thereof.

Unless otherwise defined, all terms used herein, including technical or scientific terms, have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. Terms such as those defined in commonly used dictionaries should be construed as meaning consistent with meaning in the context of the relevant art and are not to be construed as ideal or overly formal in meaning unless expressly defined in the present application .

On the other hand, if an embodiment is otherwise feasible, the functions or operations specified in a particular block may occur differently from the order specified in the flowchart. For example, two consecutive blocks may actually be performed at substantially the same time, and depending on the associated function or operation, the blocks may be performed backwards.

Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the accompanying drawings. The same reference numerals are used for the same constituent elements in the drawings and redundant explanations for the same constituent elements are omitted.

1 shows a configuration of a system 10 for off-line delegation of IoT device access rights according to one embodiment of the present invention.

First, the system 10 may include a target device 100, an owner terminal 200, and a subject terminal 300. Each of the components provided in the target device 100, the owner terminal 200, and the using subject terminal 300 may be a software module having the functions described below.

The target device 100 is a device that hosts a resource to be accessed. Devices capable of communicating with other devices such as smart cars and smart TVs and having a computing function may be an example of the target device 100. [

The owner terminal 200 may be a computing terminal capable of being owned by the owner of the target device 100, for example, a smart phone.

The using subject terminal 300 may be a smart phone capable of accessing the target device 100 and being a computing terminal possessed by a user who intends to use the resource of the target device 100, for example, a smart phone. The using subject terminal 300 may be one (300-1) or plural (300-1, 300-2). The using subject terminal 300-1 or 300-2 delegates the access right to the target device 100 from the owner terminal 200 of the target device 100 or the terminal 300-1 of the upper use subject Delegator The target device 100 can access the target device 100 through the Delegation. When the delegable token (Delegable Token) is issued from the owner terminal 200, the first user agent terminal 300-1 grants authority to the second user agent terminal 300-2 within the scope of authority granted to the first user agent terminal 300-1 . In this case, the first user principal terminal 300-1 may be a terminal of an upper use principal and the second user principal terminal 300-2 may be a terminal of a lower use principal.

The target device 100 may include an ownership management unit 110, a token checking unit 120, and an access right checking unit 130. [ The target device 100 may also include a key store 150, a trust root 160, and a security cache 140.

The owner terminal 200 may include an ownership manager 210, a token manager 220, and an access requester 230. The owner terminal 200 may also include a key store 240 and a self-token store 250.

The first user principal terminal 300-1 includes a token management unit 310-1, an access request unit 320-1, a key store 330-1 and a token chain store 340-1. . Similarly to the first user principal terminal 300-1, the second user principal terminal 300-2 includes a token management unit 310-2, an access request unit 320-2, a key store 330-2, Chain store 340-2.

The ownership management units 110 and 210 of the target device 100 and the owner terminal 200 complete the key exchange through the proof of ownership between the owner terminal 200 and the target device 100, And issues a self-signed token. Here, the self-signed token may include information such as an owner's name, a public key, an expiration date, a signature by the owner's private key, and the like.

The token management unit 220 of the owner terminal 200 notifies the first use principal terminal 300-1 of a delegation token for proving the delegation of the access right and an access token (Access Token), and manage the issuance history of the token.

The token management unit 310-1 of the first user agent terminal 300-1 stores and manages the delegation token and the access token issued by the owner terminal 200. If the delegation token is permitted, 2 using subject terminal 300-2, an access token for proving the access right to the target device 100, and may issue a delegation token. The token management unit 310-2 of the second use principal terminal 300-2 may have a function of being unified with the token management unit 310-1 of the first use principal terminal 300-1.

The access request unit 230 of the owner terminal 200 and the access request units 320-1 and 320-2 of the first and second use-subject terminals 300-1 and 300-2 are transmitted from the target device 100 It is a module for requesting access to hosted resources.

The target device 100, the owner terminal 200 and the first and second user terminals 300-1 and 300-2 include key stores 150, 240, 330-1 and 330-2, respectively , And stores therein an error correcting code (ECC) private key and a public key that can be bound to the terminal itself.

The self-token store 250 of the owner terminal 200 stores token information self-issued to the target device 100 by the owner, that is, a self-signed delegation token and an access token ).

The token chain store 340-1 of the first user agent terminal 300-1 stores the delegation token received from the owner terminal 200 and the access token issued. The token chain store 340-2 of the second user agent terminal 300-2 stores the delegation token received from the first user agent terminal 300-1 and the access token issued. That is, the token chain stores 340-1 and 340-2 store the token information received by the terminal of the user who intends to access the target device 100. [

The token checking unit 120 of the target device 100 determines whether or not the owner terminal 200 or the using subject terminals 300-1 and 300-2 has received the token chain This is a module for verifying validity.

The access right verifying unit 130 of the target device 100 includes a module for checking whether or not the resource and the action requested by the owner terminal 200 or the use subject terminals 300-1 and 300-2 are authorized to be.

The security cache 130 of the target device 100 is a memory cache holding access privilege information.

The trust root 160 of the target device 100 can store and manage the public key PB and the name NM of the owner of the owner terminal 200.

The entities shown in FIG. 1 may have the following relationship with each other. First, the owner terminal 200 and the target device 100 may establish a mutually trusted ownership. The owner terminal 200 can access the target device 100 through the self-signed access token. The use subject terminal 300 can access the target device 100 through the access token between the using subject terminal 300 and the target device 100. [ Between the first use-principal terminal (Delegator) 300-1 and the second use-principal terminal 300-2, the first use-principal terminal 300-1 is allowed to communicate with the owner terminal 200 It can delegate authority to the other using subject terminal 300-2.

FIG. 2 illustrates an overall service flow of an offline delegation method of an IOT device access right according to an embodiment of the present invention.

After the owner of the target device 100 acquires the target device 100 (e.g., purchase / install), the owner terminal 200 exchanges the public key with the target device 100 through the setup process. (Step S10). Upon establishment of the trusted ownership relationship, the trusted root 160 receives the public key of the owner of the device and the token < RTI ID = 0.0 > The name can be stored.

The owner of the target device 100 having the trust relationship established basically has the authority to access the target device 100 and use the resources of the target device 100. [ The owner of the target device 100 can delegate authority to use the resource by accessing the target device 100 to the terminal 300 of another user (the delegatee) through its owner terminal 200 when necessary (Step S12). Delegation of access rights can be done through issuance of an access token (Access token). For example, the owner terminal 200 issues (transmits) an access token to one or more using subject terminals 300 so that the target device owner can delegate authority to the first user have. The using subject terminal 300-1 having received the access token can use the resources of the target device 100 within the delegated authority scope (S14).

The owner of the target device may issue a delegation token to the one or more using subject terminals 300 through the owner terminal 200 in addition to the access token (S16). The user agent terminal 300 having issued the delegation token may issue only the access token to the other use agent terminal 300 based on the authority range of the issued delegation token or may issue the access token together with the delegation token.

For example, referring to FIG. 2, the owner terminal 200 may issue a delegation token including an access right to the first use principal terminal 300-1 together with an access token . The first user principal terminal 300-1 not only can access the permitted resources of the target device 100 based on the access token issued by the owner terminal 200 but also can access other authorized devices based on the issued delegation token For example, an access token enabling access to the target device 100 to the user's terminal, for example, the second user terminal 300-2.

If the delegation token issued from the owner terminal 200 includes the authority to issue a delegation token to other delegate subjects other than the access token, the first delegatee terminal 300-1 300-1 may issue a delegation token to the other using subject terminal, for example, the second using subject terminal 300-2. Thus, the second user principal terminal 300-2 can access the target device 100. [ In this manner, the using subject terminal of the subject agent may issue a delegation token to another subject subject terminal in accordance with the authority range of the delegation token, in addition to accessing the target device 100 based on the access token received from the delegating authority terminal. That is, the access right to the target device 100 can be issued to other use subject terminals in a chain by using the delegation token.

The token type has an access token and a delegation token. A delegation token is a token to prove that another user has been granted authority to delegate access token issuance. The access token is a token including the right information for accessing the resources of the target device 100. [ The scope of authority that can be delegated through the delegation token is equal to or less than the authority of the access token corresponding to the "AI" field of the delegation token.

According to an exemplary embodiment, the delegation token and the access token may have the same format as shown in Figures 3 and 4, respectively.

The fields of the delegation token and access token are: TY '(Type) is a token type field having a code' D 'value indicating that it is a delegation token for a delegation token and a unique identification value indicating an access token for an access token. The 'TI' (Token Identifier) is a token ID field, which has a unique value for identifying a token, for example, a UUID random value. 'NM' (Name) indicates the name of the subject to whom the token was issued. The name recorded in this field is a human readable name. 'PB' (Public Key) is the public key field of the delegator's public key and has the public key value bound to the subject that issued the token. 'EX' (Expired) is a token expiration date field, which indicates the effective expiration date of the issued token. 'AI' (Access Token) is an access token ID field that is bound to a delegation token and has a mapping access token ID value. 'SG' (Signature) is the mandatory private key signature field, which can sign the contents of the entire token field with the private key of the token issuer. 'DE' (Device) is a target device identifier field, which may have a URI value of the target device 100. 'Access right' is an access right field, which defines an access right to the target device 100 and has an 'RE' (Access Resource) field and an 'AC' (Action) field below this field. The RE field defines the resource of the target device 100 to which access is granted, and the AC field indicates an operation that is specifically allowed to access the resource.

The token chain refers to a token that the using subject terminal 300 submits to the target device 100 to verify the authorization before sending the access request. A token chain consists of a chain of delegation tokens forwarded from the owner or parent delegate and an access token issued. Each time the access token is issued, the issued token may include the information of the subject (terminal) and the subject (terminal) that issued the token. The token chain can be formed by the information.

Figure 5 shows a chain of delegation tokens held in a token chain store and an issued delegation token and an access token. The terminal of the mandator may issue and provide the access token 410 to the terminal of the delegatee. If desired, a delegation token 420 may also be issued and provided. If the delegator's terminal has the delegation token chain 430 received from the delegating authority terminal higher than the delegating authority terminal, the delegating agent's terminal transmits the delegation token chain 430 to the terminal of the delegating entity. The terminal of the delegatee may store the issued access token 410 and the delegation token 420 and the transferred delegation token chain 430 in its own token chain store 340.

6 is a diagram for explaining a procedure for verifying the validity of a chain hierarchy using a delegation token chain. 6 illustrates an example in which the owner terminal 200 delegates the access right to the target device 100 to the first use principal terminal 300-1 and the first use principal terminal 300-2 has the second use The access right is delegated to the main body terminal 300-2 again and the delegation is hierarchically or chained up to the n-th principal body terminal 300-n in this manner.

The n-th user terminal 300-n having the access token 410 generates an arbitrary Nonce, signs it with its own private key stored in its own key store, and generates a signed Nonce. Then, the delegation token chain 430 transmitted from the n-1 using subject terminal of the signed Nonce and the mandator may be transmitted to the target device 100 to request access to the resource of the target device 100. The delegation token chain 430 includes information about the path from the self-signing token 440 to the chain of access tokens 410 that are cascaded to one or more of the usage principals.

In response to the access request, the target device 100 verifies the validity of the chain hierarchy of the delegation token chain 430. That is, the target device 100 verifies whether or not the received delegation token chain 430 has been issued from the owner terminal 200 of the device owner who is trusted by the target device 100. Specifically, the target device 100 determines whether the self-signed token 440 cascaded with the token chain 430 received from the using subject terminal 300 is trustworthy, It can be verified using the owner's trusted public key. Also, validity of the chain hierarchy can be verified through public key-based signature verification mechanisms for the remaining tokens 430-1, 430-2, ..., 430-n included in the token chain 430.

FIG. 7 shows a procedure for establishing ownership.

The owner of the device provides the owner terminal 200 with information for proof of ownership, such as a unique identification number (PIN) of the target device 100, for example after obtaining the target device 100 (e.g., purchasing and installing the device) (Out-of-Band) (step S20). The target device 100 may be, for example, a smart TV, an electronic door lock, a smart car, or the like.

The owner terminal 200 sends a request to start the ownership relationship establishing procedure while providing the ownership verification information to the target device 100 (step S22). The proprietary verification information includes (i) a public key of the owner terminal 200 (which is managed by the key store 240), (ii) a name recognizable to the owner terminal 200 ), And (iii) information for verifying ownership of the target device 100 mentioned above.

The target device 100 verifies the reliability of ownership of the target device 100 of the owner terminal 200 using the provided ownership authentication information (S24).

The target device 100 stores the public key and name of the owner provided by the owner terminal 200 that has passed the ownership reliability verification in the trust root 160 (step S26). (E.g., owner) information trusted by the target device 100 can be managed in the local repository, which is the trusted root 160.

The target device 100 provides the resource meta information to the owner terminal 200 (step S28). The resource meta information can be composed of one or more sets of resources containing the following information: {resource name, resource identifier, action list} [1..N] where 'resource name' The name of the accessible location of the device 100, for example, in the case of a smart car, can be represented as a human readable string such as 'Car Engine'. The 'resource identifier' is information that can uniquely identify a resource in the target device 100, that is, a unique resource identifier (URI), and can be included in the 'RE' field of the access token. An 'Action list' is a list of operations that can be taken on a resource and is a value that can be included in the "AC" field of the access token. For example, if the smart car resource has a driving start and a trunk opening / closing operation, the resource meta information may be displayed as follows.

{"Smart Car", "/ Car", {"A1", "A2", "A3"}}

The owner terminal 200 stores resource meta information provided from the target device 100, which is used for accessing the resource of the target device 100 (S30).

In addition, the owner terminal 200 issues a self-signed delegation token and an access token to the self-signed token store 250 (S32).

Through this process, a trusting relationship can be established between the owner terminal 200 and the target device 100 that the owner terminal 200 has ownership of the target device 100. In the process of establishing a trusted proprietary relationship, the exchange of information between the owner terminal 200 and the target device 100 can be performed in a direct communication (peer-to-peer communication) manner without using the Internet.

FIG. 8 shows an example of a scenario for delegating access authority to a target device. The illustrated scenario relates to the case where the device owner delegates an access right having delegation authority to a first user (Subject_1) and a first user (Subject_1) delegates an access right without a delegation right to a second user (Subject_2). When delegating a permission with delegation authority, it issues a delegation token and an access token. On the other hand, when only delegation authority is delegated, only an access token is issued. The delegator delivers to the delegatee a list of delegation tokens received from the owner and from the delegatee and the delegation tokens and access tokens that he or she has issued for the delegatee. The transferred delegation token and the issued token are stored in the token store of the payer.

In this scenario, the terminal 200 of the device owner who has established a trust relationship with the target device 100 issues an access token 510 and a self-signed token 520 and stores it in the self-token store 250. In order to delegate authority to delegate authority to the use principal terminal 300-1 of the first user (Subject_1), an access token 530 and a delegation token 540 are issued, and together with the self-signature token 520, 1 to the using subject terminal 300-1 of the user 1 (Subject_1). The first user agent terminal 300-1 stores the received tokens 520, 530, and 540 in the token chain store 340-1. The first user (Subject_1) issues an access token (550) in order to delegate to the second user (Subject_2) without authorization to delegate the second user (Subject_2) with the self-signed token (520) and the delegation token (540) To the using subject terminal 300-2 of the subject subject_2. The second user agent terminal 300-2 stores the received tokens 520, 540 and 550 in the token chain store 340-2.

FIG. 9 specifically shows a procedure for delegating access authority to the target device 100. FIG.

First, the delegating terminal 300a (e.g., the owner terminal 200) delegates the access right to the resource of the target device 100 to the delegating terminal 300b (e.g., the first use principal terminal 200) A procedure for specifying the purported terminal 300b is performed. Specifically, this specific procedure is as follows.

First, the delegating terminal 300a determines whether a delegation trigger (step S40) (refer to the description of the delegation trigger processor in FIG. 10) (Step S42), and then a delegation negotiation request (Negotiate Delegation) is performed to the delegated terminal 300b (step S44). The delegated terminal 300b acquires the nonce generated in the delegating terminal 300a (step S46). The pseudo-terminal 300b transmits the obtained Nonce to the delegation terminal 300a (Negotiation ACK) (S48). The delegating terminal 300a verifies whether the nonce received from the delegated terminal 300b is identical to the nonce generated by the delegating terminal 300a in step S50. If the verification result is the same, it can be seen that the pseudo delegation terminal 300b is specified.

If the delegated terminal 300b is specified, the delegating terminal 300a requests the delegated terminal 300b to send the delegator's public key (step S52).

In response to the request, the delegated terminal 300b transmits the delegator's public key to the delegating terminal 300a (step S54). The proxy terminal 300a may further provide a proof of position (POP) value signed with the private key of the delegator who matches the public key with the public key. The reason for providing the POP value is to prove that you have a private key that matches the public key.

The delegating terminal 300a includes the public key of the delegating terminal 300b and the access right to the resource of the target device 100 in the field "PB", generates an access token signed with the delegator's private key, (Step S56).

The delegation token chain and the issued token are transmitted to the pseudo-terminal 300b (step S58). At this time, the delegating terminal 300a may issue a delegation token in addition to the access token (details will be described later).

The delegated terminal 300b stores the received tokens in the token chain store 340b (step S60).

The exchange of information between the delegation terminal 300b and the delegated terminal 300b may be performed in a direct communication (peer-to-peer communication) manner without going through the Internet. However, in order to prevent the token from being issued to the undesired terminal, the information transmission method that does not use the communication interface (non-communication) is the same as the method in which the delegating terminal 300b acquires the Nonce generated by the delegating terminal 300a . For example, the delegating terminal 300a generates a Nonce in the form of a QR code, a barcode, or a PIN, and displays it on the screen. The delegating terminal 300b receives the non- A method of recognizing the QR code or barcode information displayed on the screen of the delegating terminal 300a through a keypad or a method of directly inputting the PIN number of the delegated person to the delegating terminal 300b.

10 is a flow diagram illustrating the delegation trigger process.

To start the delegation procedure, the delegating terminal 300a first loads the token 600 issued to the delegating terminal 300a from the token chain store 340 (step S70). If the delegation token 610 exists in the issued token 600, the next step is performed (S72). The access right ("AR") field is decoded by parsing the access token 620 (step S74), and the decoded access right value is displayed on the delegation terminal 300a screen (step S76). The owner / delegator starts the delegation action after selecting the delegation authority among the displayed resource ("RE") and the action ("AC") item (S78).

Next, FIG. 11 shows a request for accessing a resource of a target device of the terminal and a procedure for verifying the request.

The using subject terminal 300 generates a token payload through the access request unit 320 to access the resource of the target device 100 in step S80 and transmits the payload to the target device 100 in step S82 ).

Figure 12 shows the token payload creation process in more detail. When the application of the access requesting unit 320 of the using subject terminal 300 requests the generation of the token payload, the nonce is generated and signed with the private key of the using subject terminal 300 stored in the key store 330 And generates a signed Nonce (Signed Nonce). The token payload is composed of the signed Nonce and the chain of tokens stored in the token chain store (340). Here, the token chain is the sum of the access token and the chain of delegation tokens received from the delegator. The configured token payload is returned to the application of the access request unit 320. [

The target device 100 having received the token payload verifies the validity of the token payload through the permission checking unit 130 (step S84). The validation is based on information about the trusted owner relationship of the target device owner stored in trust root (160).

If the submitted token payload passes the validation, the target device 100 extracts the 'access right information for the target device 100 resource' of the access token contained in the token payload and stores it in the secure cache 140 (Step S86).

Then, the target device 100 generates a session ID matching the token payload and returns to the using subject terminal 300 (S88). The using subject terminal 300 can then communicate with the target device 100 via the session ID.

The using subject terminal 300 sends an access request message including the URL of the target device 100 resource to be accessed to the target device 100 in step S90. At this time, the session ID received from the target device 100 is included in the payload of the access request message.

The target device compares the access request message received from the using subject terminal 300 with the 'access right information corresponding to the Session ID' stored in the security cache 140 to determine whether the access request message of the using subject terminal 300 is valid or not (Step S92).

If the verification result shows that it is authorized, the access is permitted. If it is determined that the access is not authorized, the access is denied. In addition, the access history is stored in the secure cache 140. [ When the back-end server is connected to the Internet, the access history can be stored in the Audit DB of the back-end server.

13 shows a procedure for verifying the validity of the token payload presented by the using subject terminal in the target device.

The application of the permission checking unit of the target device 100 extracts a token chain from the token payload received from the using subject terminal 300 (step S100). In step S102, it is determined whether a self-signed token exists in the extracted token chain (step S102). If there is no self-signed token, unauthorized processing is performed (step S108).

If a self-signed token exists, the self-signed token is verified. Specifically, the "name" and "public key" stored in the trust root 160 are compared with the public key of the "Public Key" field and the name of the "name" field of the root token in the self- (Step S106). If they do not coincide with each other, the process is rejected (step S108).

If they match, the signature of the delegation token chain is verified by extracting the public key of the delegator (step S110). Specifically, it is checked whether or not the delegation token exists (step S112). If the delegation token exists, the delegation token is verified (step S114). If the verification result is valid (S116), verification is performed on the entire delegation token constituting the delegation token chain in a manner of performing verification on the next delegation token constituting the delegation token chain (S112, S114). If none of the entire delegation token chains pass the validation, an unauthorized process is performed (step S108), and if all of the validation passes, the process proceeds to the verification process for the access token.

The verification logic for such a chain of delegation tokens can be expressed as:

for i = 1 to number of (Delegation Token) {

if i = 1 then Pub_Key = Public Key of Self Signed Token

else Pub_Key = Public Key of Delegation Token [i-1]

Verify "SG" value of Delegation Token [i] with Public_Key

}

After the delegation token is verified, the validity of the access token is verified (step S118). To do this, the delegator, that is, the public key of the terminal that issued the access token, is extracted. Specifically, if there is a delegation token in the token chain (Case 1), the public key is extracted from the "PB" of the delegation token located at the bottom of the delegation token hierarchy. If the delegation token does not exist, the public key is extracted from the "PB" of the self-signed token.

The validity of the access token is verified with the extracted public key (step S120). If it is determined to be invalid, the process is unauthorized (step S108). If it is confirmed to be valid, Proof-of-Possession verification is performed (step S122). This verification is to verify the signature of the signed Nonce (Signed Nonce) of the payload with the public key of the access token.

If it is determined that the verification result is not valid, the process is unauthorized (step S108). If it is determined to be valid, a security cache is generated and updated with the authority information extracted from the access token (step S126). The value of "SI" (session ID) is the session ID of the UUID random value, and the fields "EX" (valid period) and "AR" (permission) are information extracted from the access token.

In the above description, the information exchange between the target device 100, the owner terminal 200, and each of the using subject terminals 300-1, 300-2, ..., 300n is performed by the non- A peer-to-peer communication method using, for example, a Bluetooth communication method or the like. Therefore, the present invention can be implemented in an offline environment in which an Internet connection is not possible.

The present invention can be widely used for sharing the access right of resources of the target device among the IoT devices by delegation method.

It will be apparent to those skilled in the art that various modifications and variations can be made in the present invention without departing from the spirit or scope of the present invention as defined by the following claims. It will be understood.

100: target device 110: ownership management unit
120: Token checking unit 130: Permission checking unit
140: Secure Cache 150: Key Store
160: trust root 200: owner terminal
210: ownership management unit 220: token management unit
230: access request section 240: key store
250: Self-token store
300, 300-1, 300-2, ..., 300-n:
310-1 and 310-2: Token management units 320-1 and 320-2:
330-1 and 330-2: key stores 340-1 and 340-2: token chain stores

Claims

A delegation step of providing an access right of an owner terminal of an owner having a trusted owning relationship to the target device to access the resource of the target device to the first use subject terminal of the first user;
An access step in which the first use-principal terminal makes an access request to the resource of the target device based on the access right; And
And a verification step of verifying, in the target device, the access request based on the information about the trusted ownership relationship and determining whether to permit access to the target device of the first use subject terminal according to the verification result ,
Wherein the delegating comprises:
Identifying the first user principal terminal so that the owner terminal delegates an access right to the resource of the target device to the first user principal terminal;
The owner terminal requesting the first user's public key to the first user principal terminal;
Providing the first user's public key to the owner terminal in response to a public key request of the first user; And
The owner terminal issuing a second access token to the first user principal terminal and providing the access right to the first user principal terminal,
Wherein the second access token includes information at least including a public key of the first user, an expiration date of the token, access right information for the resource of the target device, and information signed by the owner's private key. How to delegate access rights.

2. The method according to claim 1, further comprising the step of establishing ownership of the owner's trusted ownership relationship with the target device prior to the delegation step. Way.

3. The method as claimed in claim 2,
Requesting the owner terminal to establish the ownership relationship, while providing the ownership verification information including the public key of the owner terminal, the name, and the proof of ownership that can prove ownership of the target device to the target device;
Verifying the reliability of ownership of the target device of the owner terminal using the ownership authentication information provided by the target device;
Storing a public key and a name of an owner of the target device that has passed the verification of trustworthiness of ownership;
Providing the owner terminal with resource meta information used by the target device to grant access to its resource; And
The owner terminal generates a first access token for authenticating the self-signed token signed by the owner and the access right to the resource of the target device, and stores the generated first access token in a self-signed token store The method comprising the steps of:

4. The apparatus of claim 3, wherein the resource meta information includes at least a name of an accessible resource of the target device, a unique identifier of the resource, and an action list, How to delegate access rights.

4. The method according to claim 3, wherein the self-signed token includes signature information by at least an owner's name, a public key, an expiration date, and an owner's private key.

delete

The method of claim 1, wherein the step of identifying the first user terminal comprises: acquiring an arbitrary temporary value (Nonce) generated by the owner terminal by the first user principal terminal; Returning a response message (ACK) including the nonce acquired by the first user principal terminal to the owner terminal; Verifying whether the nonce returned by the owner terminal is the same as the nonce generated by the owner terminal; And if the verification is passed, identifying the first user equipment terminal as a delegated terminal.

8. The method according to claim 7, wherein the method for acquiring the Nonce by the first user equipment terminal is a non-communication information transfer method that does not use a communication interface.

8. The method of claim 7, wherein the information exchange between the target device, the owner terminal, and the first user principal terminal is performed in a peer-to-peer communication manner except when the first user principal terminal obtains the Nonce A method for delegating access privileges between feature IoT devices.

2. The method of claim 1, wherein the delegation step comprises: in response to a request for a public key of a first user, the first user principal terminal transmits, in addition to the public key, a POP signed with a private key of the first user matching the public key further comprising providing a proof of position value to the owner terminal. < RTI ID = 0.0 > 11. < / RTI >

The method of claim 1, wherein the first user principal terminal having received the second access token generates a token payload to access the resource of the target device and submits the token payload to the target device, A nonce signed with the private key of the first user; a token chain that combines the second access token with a self-signed token signed by the owner received from the owner terminal; the self-signed token includes at least an owner's name, Key, expiration date, signature information by the owner's private key;
Verifying the validity of the token payload submitted by the first use subject terminal based on the information on the trusted ownership relationship of the owner;
The target device extracts the 'access right information on the resource of the target device' included in the token payload whose validity is verified, stores it in the memory, generates a session ID corresponding to the extracted access right information, Providing a using subject terminal;
Providing the target user terminal with an access request message for a desired resource of the target device together with the session ID;
The target device compares the access request message received from the first user equipment terminal with the access privilege information corresponding to the session ID stored in the memory to determine whether the access request of the first user equipment terminal Verifying whether the user has authority; And
Further comprising a step in which the target device applies or does not grant an access request of the first user equipment terminal based on the verification result.

The method of claim 1, wherein the delegation step comprises: generating the first delegation token by the owner terminal, wherein the first delegation token is transmitted to the second user terminal of the second user, An authority to issue a third access token having access rights to a resource of the device; And providing the first user principal terminal with a token chain including the first delegation token and the self-signed token signed by the owner,
Wherein the self-signed token includes signature information by at least an owner's name, a public key, an expiration date, and an owner's private key,
Wherein the first delegation token includes at least a name of the delegator, a public key of the delegator, an expiration date of the token, an ID of an access token bound to the first delegation token, and a value signed by the delegator's private key. How to delegate access between.

[12] The method of claim 12, wherein the first user principal terminal having received the first delegation token transmits the first delegation token to the target user terminal, based on the first delegation token, Further comprising the step of issuing the third access token having an authority to access the second user principal terminal to the second user principal terminal.

14. The method of claim 13,
Generating a token payload to access the resource of the target device and submitting the token payload to the target device, wherein the token payload is transmitted to the second user's personal And a chain of delegation tokens transmitted from the first user terminal, wherein the delegation token chain includes a self-signed token signed by the owner received from the owner terminal, A first delegation token and the third access token,
Verifying the validity of the token payload based on information about the trustee ownership of the owner;
The target device extracts the 'access right information for the resource of the target device' contained in the token payload whose validity is verified, stores it in the memory, generates a session ID corresponding to the extracted access right information, Providing a using subject terminal;
Providing the second user principal terminal with an access request message for a desired resource of the target device to the target device together with the session ID;
The target device compares the access request message received from the second user equipment terminal with the 'access right information corresponding to the session ID' stored in the memory and transmits an access request of the second user equipment terminal to the desired resource Verifying whether the user has authority; And
Further comprising the step of allowing the target device to grant or deny the access request of the second user equipment terminal based on the verification result.

13. The IoT device according to claim 12, wherein a range of authority to delegate to the first delegation token is equal to or narrower than that of the second access token, which is an access token bound to the first delegation token. The method of delegating the access rights between.

13. The method of claim 12, wherein if the first delegate token received from the owner terminal further includes a re-delegation authority, And issuing a second delegation token to the second usage subject terminal,
And the second delegation token includes an authority to issue a fourth access token having an access right to the resource of the target device to the third user principal terminal of the third user. How to delegate access rights between IoT devices.