KR20170114927A - Method and apparatus for providing light weight authentication protocol for mobile sensor network - Google Patents

Abstract

A method and apparatus are provided for providing a lightweight authentication protocol for a mobile sensor network. The base station uses group key encryption to broadcast time-based key generation arguments to group members. Each group member uses an irreversible function to create a commitment key generator. Each group member uses a commitment key generator to create a key generator chain. Each key of a chain of keys may be valid at a predetermined time interval for each key. The verifier of the ticket can perform authentication on the sensor node based on a chain of keys.

Description

METHOD AND APPARATUS FOR PROVIDING LIGHT WEIGHT AUTHENTICATION PROTOCOL FOR MOBILE SENSOR NETWORK [

The following embodiments are designed to establish a secure mutual authentication protocol for sensor nodes and sink nodes in a dynamic environment.

In a network system, entities of the network system may dynamically join or leave the network system.

In joining and leaving the network system, Kerberos issues a ticket for re-authentication. In addition, in joining and leaving the network system, TESLA encrypts the authentication ticket by using a time-based key chain mechanism.

In addition, Needham-Schroeder, Kerberos, Wide-Mouth-Frog and Woo-Lam, etc. maintain a session key between entities )do.

U.S. Patent No. 8,300,830 has been disclosed in connection with a communication technique between a plurality of nodes using a key.

One embodiment may provide an apparatus and method for using a secure, light weight authentication protocol for dynamic mobile networks.

One embodiment may provide an apparatus and method for allowing communication entities to authenticate with minimal communication complexity.

One embodiment may provide an apparatus and method for reducing authentication procedure delays and reducing energy consumption of sensor nodes by communicating with minimal communication complexity by communication entities.

On one side, generating a chain of keys for authentication to a communication entity in the network, performed by the base station of the sensor network; And performing authentication on the sensor node based on the chain of keys, wherein each key in the chain of keys is valid in a predetermined time interval for each key.

In addition, there is further provided another method, apparatus, system for implementing the invention and a computer readable recording medium for recording a computer program for executing the method.

An apparatus and method for using a secure, light weight authentication protocol for dynamic mobile networks are provided.

An apparatus and method are provided for enabling communication entities to authenticate with minimal communication complexity.

An apparatus and method are provided for reducing authentication procedure delays and reducing energy consumption of sensor nodes by communicating with communication entities with minimal communication complexity.

1 illustrates a sensor network according to one embodiment.
2 is a structural view of a base station according to an embodiment.
3 is a block diagram of a sink node according to an embodiment of the present invention.
4 is a structural diagram of a sensor node according to an embodiment.
5 is a flow diagram of a user node according to one embodiment.
6 is a flowchart of an authentication method according to an embodiment.
7 shows a time frame associated with the generation and use of time-based keys according to an example.
Figure 8 shows the generation and admission of time-based keys in relation to a time passage according to an example.
9A shows the structure of function g according to an example.
9B shows the structure of a function F according to an example.
9C shows the structure of a function f according to an example.
FIG. 10 shows a binary hash tree of an index vector according to an example.
11 illustrates management of a generator of a chain of keys in a sink node according to an example.
12 is a flowchart of an authentication procedure according to an example.
13 is a flowchart of SAAP according to an example.
14 is a flow chart of the SRP 1 according to an example.
15 is a flow chart of SRP2 according to an example.
16 is a flow diagram of a UAAP according to an example.
17 is a flow chart of USeAP according to an example.

The following detailed description of exemplary embodiments refers to the accompanying drawings, which illustrate, by way of illustration, specific embodiments. These embodiments are described in sufficient detail to enable those skilled in the art to practice the embodiments. It should be understood that the various embodiments are different, but need not be mutually exclusive. For example, certain features, structures, and characteristics described herein may be implemented in other embodiments without departing from the spirit and scope of the invention in connection with an embodiment. It is also to be understood that the location or arrangement of the individual components within each disclosed embodiment may be varied without departing from the spirit and scope of the embodiments. The following detailed description is, therefore, not to be taken in a limiting sense, and the scope of the exemplary embodiments is to be limited only by the appended claims, along with the full scope of equivalents to which such claims are entitled, if properly explained.

In the drawings, like reference numerals refer to the same or similar functions throughout the several views. The shape and size of the elements in the figures may be exaggerated for clarity.

The terms used in the examples are intended to illustrate the embodiments and are not intended to limit the invention. In the examples, the singular includes the plural unless otherwise stated in the specification. It is noted that the terms "comprises" and / or "comprising" used in the specification are intended to be inclusive in a manner similar to the components, steps, operations, and / And that additional configurations may be encompassed within the scope of the embodiments of the exemplary embodiments or the technical ideas of the exemplary embodiments. When it is mentioned that a component is "connected" or "connected" to another component, the two components may be directly connected or connected to each other, It is to be understood that other components may be present in the middle of the components.

The terms first and second, etc. may be used to describe various components, but the components should not be limited by the terms above. The above terms are used to distinguish one component from another. For example, without departing from the scope of the right, 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.

In addition, the components shown in the embodiments are shown independently to represent different characteristic functions, which does not mean that each component is composed of separate hardware or one software constituent unit. That is, each component is listed as each component for convenience of explanation. For example, at least two of the components may be combined into a single component. Also, one component can be divided into a plurality of components. The integrated embodiments and the separate embodiments of each of these components are also included in the scope of the right without departing from the essence.

Also, some components are not essential components to perform essential functions, but may be optional components only to improve performance. Embodiments may be implemented only with components that are essential to implementing the essentials of the embodiments, and structures within which the optional components are excluded, such as, for example, components used only for performance enhancement, are also included in the scope of the right.

Hereinafter, embodiments of the present invention will be described in detail with reference to the accompanying drawings in order to facilitate embodiments of the present invention by those skilled in the art. In the following description of the embodiments, detailed description of known functions and configurations incorporated herein will be omitted when it may make the subject matter of the present disclosure rather unclear.

The following embodiments may be related to mutual authentication between a sink node and a sensor node. Here, the sensor nodes may dynamically join and / or leave the network system.

Sensor nodes can move across the network and re-authenticate with very simple tickets based on re-authentication procedures.

In addition, the sensor node may establish a concurrent connection with multiple sink nodes. In order to establish multiple connections, it may be permissible to run multiple instances of the protocol to the sensor node. The sensor node can use re-authentication tickets to establish concurrent connections.

In an embodiment, a mechanism of key generation and distribution according to time-assisted authentication protocol (TAP) may be used. The TAP may issue a ticket for re-authentication in the sensor network (100). In addition, the TAP can encrypt the authentication ticket using a time-based keychain mechanism.

The procedure of generating and distributing the key may be used to encrypt the authentication ticket using a time-based key. Also, the key generation and distribution procedure can manage the session key between the sink node and the sensor node. The session key is specific to the sensor node and can be derived from time-based information. The sensor node may use the same session key to communicate with multiple sink nodes.

In the following embodiments, although the sensor node is re-authenticated using the same ticket, another secure mode may be introduced in which multiple private session keys are established. In addition, the workload for the sink node to re-issue the ticket and session keys may be distributed across the validity time of the commitment key generator.

1 illustrates a sensor network according to one embodiment.

In FIG. 1, an example of an overall system architecture according to embodiments is shown.

Internet of Things (IoT) Smart Services is deploying a Wireless Sensor Network (WSN) with various base stations connected to the Internet through a service center.

The sensor network 100 may include a base station (BS), a sink node (S), a sensor node (N), and a user node (U) 141 .

In the sensor network 100, the base station may be plural. As a plurality of base stations, BS ₁ 111, BS ₂ 112 and BS ₃ 113 are shown in FIG.

In the sensor network 100, there may be a plurality of sink nodes. As a plurality of sink nodes, S ₁ 121, S ₂ 122, S ₃ 123, S ₄ 124, S ₅ 125 and S ₆ 126 are shown in FIG.

The area of the sink node is indicated by a circle. Each circle is indicated by a solid line, a dot-dash line, and a dotted line, respectively, depending on which base station the sink node is associated with.

In the sensor network 100, there may be a plurality of sensor nodes. As a plurality of sensor nodes, N ₁ 131 and N ₂ 132 are shown in FIG.

In Fig. 1, U ₁ 141 is shown as a user node. In the following, "user node" can be outlined as "user ".

In the WSN, N ₁ 131 may be initially authenticated by BS ₁ 111. Further, by moving within the network, N ₁ (131) is a re-authentication may be - again by the authentication ticket. N ₁ 131 at the final destination shares data with multiple sink nodes while user node U ₁ 141 collects data from sensor node N ₂ 132 and sink node S ₁ 121 .

Base station

The base station can know public keys of all sink nodes and all sensor nodes in advance.

The base station can perform authentication and issue a ticket T _k based on time for re-authentication. In addition, during the authentication process, the base station can send a "sensor node ' s requirement profile" to the sink node for efficient and optimized relationship between sensor nodes and sink nodes.

Hereinafter, the "requirement profile" can be outlined as "profile ".

Sink node

Upon receipt of a ticket T _k based on a valid time, the sink node performs re-authentication for the mobile sensor node.

In addition, the sink node may be responsible for re-issuing the ticket with the authenticated sensor note.

For some applications, the sink node may be split into two parts. For example, the two parts may be a service delivery area A _s and a communications area A _c . The sink node can perform authentication or forward the request to the base station if the sensor node is within A _s . The sink node may also provide the service (s) to the sensor node once the sensor node has entered A _c .

Sensor node

The sensor node may be responsible for initiating the authentication procedure. The authentication procedure can be initiated by requesting authentication of the sensor node.

In most Internet of Things (IoT) applications, it may be required that sensor nodes collect different types of data and share the collected different types of data with different sink nodes. Therefore, the sensor node needs to be authenticated by multiple sink nodes, as shown in Fig. For example, N ₁ can communicate with S ₅ (125) and S ₆ (126) at the same time.

Similarly, user node U ₁ 140 may communicate with sink node S ₃ 1123 and sensor node N ₂ 132 simultaneously. In such an application scenario, when the sensor node or the user node moves across the network, the frequency of the re-authentication process may increase in proportion to the number of simultaneous connections.

The following embodiments may be developed with consideration of the following constraints.

1) Communication channels may not be secure.

2) An intruder with the ability to launch various attacks can emerge.

3) Due to the requirements of the WSN employed in the IoT environment, it may be allowed to execute multiple instances of the protocol to the protocol participants.

4) User nodes and sensor nodes can move across the network.

Under such flexibility, a completely secure authentication protocol using TAP needs to be provided.

2 is a structural view of a base station according to an embodiment.

The base station 200 of FIG. 2 may represent the base station BS of the embodiments.

The base station 200 may include a processing unit 210, a communication unit 220, and a storage unit 230.

The processing unit 210 may process a job required for the operation of the base station 200. [ The processing unit 210 may execute the code of the operation or step of the processing unit 210 described in the embodiments.

The processing unit 210 may perform generation and processing of data or information, and may perform inspection, comparison, and judgment related to data or information. In other words, in the embodiment, the generation and processing of data or information and the inspection, comparison and judgment relating to data or information can be performed by the processing unit 210. [

For example, the processing unit 210 may perform encryption and / or decryption of data or information. The processing unit 210 may generate a message.

For example, the processing unit 210 may be at least one processor.

The communication unit 220 may receive data or information required for the operation of the base station 200 and may transmit data or information required for the operation of the base station 200.

The communication unit 220 can transmit data or information to another device in the network, and can receive data or information from another device. In other words, in the embodiment, transmission or reception of data or information can be performed by the communication unit 220. [

For example, the communication unit 220 may be a networking chip, a networking interface, or a communication port.

The storage unit 230 may store data or information required for operation of the base station 200. In an embodiment, data or information possessed by the base station 200 may be stored in the storage unit 230.

For example, the storage unit 230 may be a memory. The storage unit 230 may include a built-in storage medium such as a RAM and a flash memory, and may include a removable storage medium such as a memory card or the like.

The storage unit 230 may store at least one program. The processing unit 210 may execute at least one program. The processing unit 210 can read the code of at least one program from the storage unit 230 and execute the read code.

Operations, functions, and characteristics of the processing unit 210, the communication unit 220, and the storage unit 230 of the base station 200 will be described in detail below with reference to embodiments.

3 is a block diagram of a sink node according to an embodiment of the present invention.

The sink node 300 of FIG. 3 may represent the sink node S of the embodiments.

The sink node 300 may include a processing unit 310, a communication unit 320, and a storage unit 330.

The processing unit 310 may process a task required for the operation of the sink node 300. [ The processing unit 310 may execute the code of the operation or step of the processing unit 310 described in the embodiments.

The processing unit 310 may perform the generation and processing of data or information, and may perform inspection, comparison, and judgment related to data or information. In other words, in the embodiment, the generation and processing of data or information and the inspection, comparison and judgment relating to data or information can be performed by the processing unit 310. [

For example, the processing unit 310 may perform encryption and / or decryption of data or information. The processing unit 310 may generate a message.

For example, the processing unit 310 may be at least one processor.

The communication unit 320 may receive data or information required for operation of the sink node 300 and may transmit data or information required for the operation of the sink node 300. [

The communication unit 320 can transmit data or information to another device in the network, and can receive data or information from another device. In other words, in the embodiment, transmission or reception of data or information can be performed by the communication unit 320. [

For example, the communication unit 320 may be a networking chip, a networking interface, or a communication port.

The storage unit 330 may store data or information required for operation of the sink node 300. In an embodiment, the data or information that the sink node 300 has may be stored in the storage 330.

For example, the storage unit 330 may be a memory. The storage unit 330 may include a built-in storage medium such as a random access memory (RAM) and a flash memory, and may include a removable storage medium such as a memory card or the like.

The storage unit 330 may store at least one program. The processing unit 310 may execute at least one program. The processing unit 310 can read the code of at least one program from the storage unit 330 and execute the read code.

Operations, functions, and characteristics of the processing unit 310, the communication unit 320, and the storage unit 330 of the sink node 300 will be described in detail below with reference to embodiments.

4 is a structural diagram of a sensor node according to an embodiment.

The sensor node 400 of FIG. 4 may represent the sensor node N of the embodiments.

The sensor node 400 may include a processing unit 410, a communication unit 420, and a storage unit 430.

The processing unit 410 may process a job required for the operation of the sensor node 400. [ The processing unit 410 may execute the code of the operation or step of the processing unit 410 described in the embodiments.

The processing unit 410 may perform generation and processing of data or information, and may perform inspection, comparison, and judgment related to data or information. In other words, in the embodiment, the generation and processing of data or information and the inspection, comparison and judgment relating to data or information can be performed by the processing unit 410. [

For example, the processing unit 410 may perform encryption and / or decryption of data or information. The processing unit 410 can generate a message.

For example, the processing unit 410 may be at least one processor.

The communication unit 420 may receive data or information required for the operation of the sensor node 400 and may transmit data or information required for the operation of the sensor node 400.

The communication unit 420 may transmit data or information to another device in the network, and may receive data or information from another device. In other words, in the embodiment, the transmission or reception of data or information can be performed by the communication unit 420.

For example, the communication unit 420 may be a networking chip, a networking interface, or a communication port.

The storage unit 430 may store data or information required for the operation of the sensor node 400. In an embodiment, the data or information possessed by the sensor node 400 may be stored in the storage 430.

For example, the storage unit 430 may be a memory. The storage unit 430 may include a built-in storage medium such as a RAM and a flash memory, and may include a removable storage medium such as a memory card or the like.

The storage unit 430 may store at least one program. The processing unit 410 may execute at least one program. The processing unit 410 can read the code of at least one program from the storage unit 430 and execute the read code.

Operations, functions, and characteristics of the processing unit 410, the communication unit 420, and the storage unit 430 of the sensor node 400 will be described in detail below with reference to embodiments.

5 is a structural diagram of a user node according to an embodiment.

The user node 500 of FIG. 5 may represent a user node U of embodiments.

The user node 500 may include a processing unit 510, a communication unit 520, and a storage unit 530.

The processing unit 510 may process the operation required for the operation of the user node 500. [ The processing unit 510 may execute the code of the operation or step of the processing unit 510 described in the embodiments.

The processing unit 510 may perform generation and processing of data or information, and may perform inspection, comparison, and judgment related to data or information. In other words, in the embodiment, the generation and processing of data or information and the inspection, comparison and judgment related to data or information can be performed by the processing unit 510.

For example, the processing unit 510 may perform encryption and / or decryption of data or information. The processing unit 510 can generate a message.

For example, the processing unit 510 may be at least one processor.

The communication unit 520 may receive data or information required for operation of the user node 500 and may transmit data or information required for operation of the user node 500. [

The communication unit 520 may transmit data or information to another device in the network, and may receive data or information from another device. In other words, in the embodiment, transmission or reception of data or information can be performed by the communication unit 520. [

For example, the communication unit 520 may be a networking chip, a networking interface, or a communication port.

The storage unit 530 may store data or information required for operation of the user node 500. In an embodiment, the data or information that the user node 500 has may be stored in the storage 530.

For example, the storage unit 530 may be a memory. The storage unit 530 may include a built-in storage medium such as a RAM and a flash memory, and may include a removable storage medium such as a memory card or the like.

The storage unit 530 may store at least one program. The processing unit 510 may execute at least one program. The processing unit 510 can read the code of at least one program from the storage unit 530 and execute the read code.

Operations, functions, and characteristics of the processing unit 510, the communication unit 520, and the storage unit 530 of the user node 500 are described in detail below with reference to embodiments.

In the embodiments described below, the following notations may be used for entities, information, variables, and so on.

BS _j : " BS _j " may represent the j- th base station. " BS _j " in the message may represent the j- th base station.

S _j : " S _j " may represent the jth sink node. " S _j " in the message may indicate the identifier of the jth sink node.

N _i : " N _i " may represent the i- th sensor node. The " N _i " in the message may indicate the identifier of the jth sensor node.

A △ B : "A △ B" may indicate that B is less than the control authority gateun (B is in controlling authority), A is associated with B.

- For example, " S _i △ BS _j " may indicate that S _i is associated with BS _j .

G _j : " G _j " may represent a group of all associated entities of BS _j .

_{^{G j 0: "G j 0}} " is the ratio of the BS _j knows the K _G ^j - may represent a group (group of all non-associated entities of BS _j who knows the K _G ^j) of the associated entities.

A ∈ B : " A ∈ B " can indicate that A is a member of set B.

For example, BS _i ∈ N ( BS _i ) or S _j ∈ G _i can be used to represent members of a set.

K ₀ ^j : " K ₀ ^j " may be a time-based key in the zeroth time interval. K ₀ ^j may be a commitment key. K ₀ ^j may be used in the group of BS _j .

K _i ^j : " K _i ^j " may be a time-based key in the i th time interval. K _i ^j may be generated in the i th time interval. K _i ^j can be used in the group of BS _j .

K _A ^j : " K _A ^j " may be the public key of the j- th entity A.

- K _BS ^j : " K _BS ^j " may be the public key of BS _j .

- K _S ^j : " K _S ^j " may be the public key of the sink node S _j .

- K _N ^j : " K _N ^j " may be the public key of the sensor node N _j . K _N ^j can be publicly known only to BS _j .

K _G ^j : " K _G ^j " may be a group key generated by BS _j . K _G ^j can be used in a group of BSs .

K _S ⁱ : " K _S ⁱ " may be the session key generated in the i- th time interval. K _S ⁱ may be a session key from N _i to S _j .

K _PS ⁱ : " K _PS ⁱ " may be the secret session key generated in the i- th time interval. K _PS ⁱ may be a session key from N _i to S _j .

E _B ⁱ ( m ) : " E _B ⁱ ( m )" may indicate encrypting message "m" with key K _B ⁱ . Alternatively, " E _B ⁱ ( m )" may represent an encrypted message "m" using key K _B ⁱ .

E _BS ^j ( m ) : Alternatively, " E _BS ^j ( m )" may indicate encrypting message "m" with key K _BS ^j . ^{_{Or, "E BS j (m)}} " may represent the message "m" is encrypted using the key K _BS ^j.

V ₀ : " V ₀ " may be the value of the index for the 0 < th > time interval.

V _i : " V _i " may be the value of the index for the _i < th > time interval.

T _K : " T _K " may be the k- th ticket in the i- th time interval. T _K can be generated in the i- th time interval.

Z ( A ) : " Z ( A )" may be an intruder Z impersonating entity A.

N _i : " N _i " may be the i- th nonce in the message exchange.

H () : " H ()" may be a one-way high entropy hash function.

6 is a flowchart of an authentication method according to an embodiment.

The embodiments described below may include two sub-innovation parts. The two sub-innovation parts may be 1) key generation and distribution based on enhanced time and 2) authentication procedure of the mobile sensor node.

A simple sketch of the proposed scheme in embodiments may be defined as steps 610 and 620 below.

In step 610, the generation and distribution of a time-based key may be performed.

1. Each BS can generate key generation information of a time-based key using group key encryption. The key generation information may include one or more generation arguments.

2. Each BS may broadcast key generation information so that members of the group receive generation parameters. Each BS can broadcast the key generation information of the time-based key using encryption using the group key.

Each BS can broadcast key generation information KEY _msg after every time interval T _d . All members of the group can receive the key generation information KEY _msg from the BS .

3. Every member of the group can generate a commitment key generator G ₀ ^j using key generation information KEY _msg and an irreversible function g , respectively.

4. All members of the group can generate a "chain of keys generator" using the commitment key generator and irreversible function F , respectively. The length of the constructor of the chain of keys may be L. The keys may be generated in a reverse order of the order in which the keys are used by F.

In step 620, authentication may be performed.

Of the chain of keys, the i- th key may only be valid in the i- th index. That is, each key of a chain of keys may be valid at a predetermined time interval for each key.

1. When N wants to join during the i- th time interval, N may acquire an authentication ticket encrypted with the i- th key.

2. BS or S can perform authentication for N using a ticket. The BS or S , the verifier of the ticket, can perform authentication on N based on a chain of keys. The BS or S may examine the ticket by decrypting the ticket using the i- th key of the chain of keys. Here, the selected i- th key may be a key corresponding to the time interval during which service is provided to N in the chain of keys.

The proposed scheme of embodiments

As described above, the scheme for the embodiments may consist of two major parts. The two main parts may be 1) generation and distribution of keys based on time and 2) authentication and re-authentication of sensor nodes.

In the following embodiments, along with the time-based key K _i ^j , two major parts are described in detail.

group

Each base stays line BS _j of the sensor network 100 may form a group G _j . G _j may include 1), BS _j, 2) of the BS _j neighbor BS (N (BS _j)) and 3) of the sink node {S _j △ BS _j} associated with BS _j. Here, BS _j may be a group leader.

G _j can be defined as Equation (1) below.

N can represent a neighbor.

Time-based keys

7 shows a time frame associated with the generation and use of time-based keys according to an example.

In Fig. 7, time may be indicated as flowing from left to right. For example, after the elapse of T _G , the interval of T _Dis may start. After the lapse of T _Dis , the interval of T _d may start.

The time frame may be divided into three periods. The three periods may be T _G , T _Dis and T _d . T _G may be the time required for key generation. T _Dis may be the time required for key distribution. T _d may be a valid time for the commit key K ₀ ^j .

Figure 8 shows the generation and admission of time-based keys in relation to a time passage according to an example.

All members of G _j may generate the commit key K ₀ ^j using the key generation information KEY _MSG .

For example, a KEY _MSG can be sent to a member encrypted with the member's public key at the time the member of the group joins the group. Through this transmission, the KEY _MSG can be shared among the members of the group.

After every time interval T _d , BS _j may broadcast the KEY _MSG to all members of G _j . The broadcast KEY _MSG can be encrypted with the group's group key K _G ^j . Alternatively, for time-synchronized systems, the broadcast KEY _MSG may be encrypted with a time-based key K _l ^j . Here, K _l ^j may be the final key of the keychain.

The procedure and all the properties of the key generation can be controlled by the leader BS _j of the group.

The key generation information KEY _MSG can be defined as Equation (2) below.

The key generation information KEY _MSG may include pieces of some information.

KEY _MSG may comprise a ^{_{lookup, T d, T c j}} , N 0 j, L and MODE.

A secret table can be shared for data to be used in common among all the objects in the group.

I can represent an index for selecting a value from a table of secrets. O may represent an offset for selecting a value from a table of secrets. The values of I and O may be determined randomly by BS _j .

lookup ( I , O ) may be the value of the position determined by index I and offset O of the table. I and O may select a particular value from the table. For example, lookup ( I , O ) may represent a value extracted from index I and offset O in a table of secrets.

T _d may be a valid time duration for the commitment key K ₀ ^j .

T _c ^j may be a time at the BS when the BS _{j j} broadcast KEY _msg.

L may represent the length of the constructor of the chain of keys. Alternatively, L may be the time duration of the keychain.

The number of time-based keys in the chain of keys may be L. T _d may be divided into L time intervals.

N ₀ ^j may be a nonce determined by BS _j .

MODE may indicate a key retrieval mode. The elements of the KEY _MSG described above are described in more detail below.

Key generation and distribution procedures

KEY After a successful distribution of _msg , all members of G _i can do the following tasks.

Members can use the information in the KEY _MSG to generate a chain of commit key generators G ₀ ^j and keys.

1) The member can run the function g to generate the commit key generator G ₀ ^j .

G ₀ ^j can be defined as Equation (3) below.

The function g can be defined as Equation (4) below.

"는 논리적 배타합(eXclusive OR; XOR) 연산자(operatior)일 수 있다."

Quot; may be an eXclusive OR (XOR) operator.

A member can create a "chain of keys generator" using the commitment key generator G ₀ ^j and the irreversible function F. The length of the constructor of the chain of keys may be L.

The irreversible function F can be defined as Equation (5) below.

When i > 0, G _i ^j may be the generator of key K _i ^j .

i can represent the order of generation of the keys. Also, i may represent the reverse order of use of the keys, and the key may indicate the reverse order of the valid time interval.

2) F can take G ₀ ^j as an input factor, and members can use F to create a chain of length L' s.

In the generation of the chain of keys, F can be used as shown in Equation (6) below.

The value of l may be equal to L.

When the group's commit key generator is the input of the irreversible function F , the output of the irreversible function may be the generator of the last used key among the keys.

In other words, F can be defined as Equation (7) below.

When input of the k +1 of the second key generator irreversible function F, the output of the irreversible function F may be a k-th key generator. All members of G _i can generate vectors of index V and key K using another irreversible function f .

f can be defined as Equation (8) below.

Further, the pairs of V and K can be defined as Equation (9) below.

The pair of index V and key K may be generated based on irreversible functions F and f .

N ₀ ^j "는 K _i ^j 에 대응할 수 있고, 뒤의 "H(i)

N ₀ ^j "는 V에 대응할 수 있다. 키 K _i ^j 는 키의 생성자 G _i ^j 및 넌스 N ₀ ^j 에 기반하여 생성될 수 있다. 인덱스 V는 i 및 넌스 N에 기반하여 생성될 수 있다. 도 11에서 도시된 것처럼, 수학식 3 내지 수학식 8을 참조하면 그룹의 확약 키 K _o ^j 및 시간에 기반한 키들 (K ₁ ^j 내지 K _l ^j )은 기정의된 값에 기반하여 생성될 수 있다. 기정의된 값은 1) 확약 키 생성자 G _o ^j _, 2) 확약 키 K ₀ ^j 에 대한 유효한 시간 T _d 및 3) BS _j 에 의해 결정된 넌스 N ₀ ^j 의 하나 이상일 수 있다.In Equations (8) and (9), " H ( G _i ^j )

N ₀ ^j "may correspond to K _i ^j , and the following" H ( i )

N ₀ ^j "may correspond to V. The key K _i ^j may be generated based on the key generator G _i ^j and the nonce N ₀ ^j . The index V may be generated based on i and nonce N. As shown in FIG. 11, referring to equations (3) to (8), the group's commit key K _o ^j and time-based keys ( K ₁ ^j to K _l ^j ) can be generated based on a predefined value The default value may be one or more of 1) a commit key generator G _o ^j _, 2) a valid time T _d for the commit key K ₀ ^j , and 3) a nonce N ₀ ^j determined by BS _j .

The vector V and the vector K can be defined as the following Equation (10).

The members can issue an i- th key, which is used to encrypt the ticket T _k , during the i- th time interval. Since the keys are initiated in reverse order, it may not be possible for an intruder to generate future keys.

On the other hand, the index vector V may serve as an index for retrieving the key, and V _i may correspond to the i- th time interval. For example, the following expression (11) can be established.

Each constructor G in the chain can be used by the function g at specific time intervals to derive indices and a pair of ticket encryption keys. For example, for a time interval k , for any sensor node or user node i requesting BS _j to join the network, the function f may generate a ticket encryption key K _k ^j and an index V _k value. The function f can be defined as Equation (12) below.

Further, the BS _j may issue a session key K _S ⁱ based on the ticket encryption key K _k ^j and the secret ness n ₀ ⁱ . The session key K _S ⁱ can be defined as Equation (13).

Where n ₀ ⁱ may be the secret of the secret sent by node i in the network join message.

9A shows the structure of function g according to an example.

FIG. 9A is a diagram showing the structure of the function g described above with reference to the equation (4).

"는 논리적 배타합(XOR) 연산자(operatior)일 수 있다.In Fig. 9A, a symbol of a square may represent an operation such as a function. A parallelogram can represent an input value or an output value, and can represent a variable or data used as an input value or an output value. "

Quot; may be a logical exclusive (XOR) operator.

T _d

N ₀ ^j "를 나타낼 수 있다.
9A, Q is " lookup ( I , O )

T _d

N ₀ ^j ".

9B shows the structure of a function F according to an example.

FIG. 9B illustrates the structure of the function F described above with reference to Equations (5), (6), and (7).

In Fig. 9B, a symbol of a square may represent an operation such as a function. A parallelogram can represent an input value or an output value, and can represent a variable or data used as an input value or an output value. A rhombus can represent a conditional branch according to the result of a comparison.

9C shows the structure of a function f according to an example.

FIG. 9C is a diagram illustrating the structure of the function f described above with reference to Equation 8 and Equation 9. FIG.

"는 논리적 배타합(XOR) 연산자(operatior)일 수 있다.
In Fig. 9C, a symbol of a square may represent an operation such as a function. A parallelogram can represent an input value or an output value, and can represent a variable or data used as an input value or an output value. "

Quot; may be a logical exclusive (XOR) operator.

T _k  Extraction modes for encryption keys

The key extraction mode may depend on the structure of the ticket and the structure of the ticket may be determined by the requirements and constraints of the sensor network 100. In the following embodiments, the first mode and the second mode, which are two different key extraction modes, are respectively described.

Structure of ticket

The structure of the authentication ticket may depend on the selected mode.

In the first mode the structure of the ticket T _k may be equal to Equation 14 below.

The structure of the ticket T _k in the second mode may be expressed by Equation (15) below.

The structure of the ticket T _k in the third mode can be expressed by the following Equation (16).

As defined in Equations (14), (15) and (16), a ticket can be classified into a first portion, which is a first half, and a second portion, which is a second half. That is to say, the ticket may include a first portion and a second portion.

The first portion and the second portion may each be encrypted with a different key. For example, the first part may be encrypted with a time-based key K _i ^j . The second part may be encrypted with the group key K _G ^j of BS _j .

First and second parts of the ticket can be derived based on information specific to the N _k, respectively.

The second part of the ticket may be mode dependent. The second part of the ticket may be different depending on the mode.

The second part may comprise information used for determining the key K _i ^j based on the time for decrypting the first part which is the front half.

A first portion of the ticket may be used to verify the T _k.

The first mode

BS _j may be added to the index value of V _i at the end of T _k. T _k may include an index value V _i .

The ticket verifier can compare the V _i of T _k with the vector V generated by the ticket verifier itself. The fact that V _i and V are matched at the i- th place (place) of V can mean that the ticket T _K can be decrypted by the key K _i ^j . So to speak, V _i of the second portion of the T _k may indicate an Is the key at any time interval of the chain of the keys used by the decoding of the first portion of T _k.

Therefore, The ticket verification can determine the key K _i ^j based on the time to decode a first portion of T _k by using the V _i of the second portion of the T _k, by using the key K _i ^j based on the determined time the 1 < / RTI >

That is to say, at least a portion of the information of the ticket T _k (i.e., the first part) can be decrypted by the key K _i ^j based on the time available at the predefined time interval.

The second mode

If the members of the group are in a completely secure environment, a simple ticket retrieval strategy may be employed in embodiments. In the second mode, instead of using the scrambled index value V in the extraction of the ticket, information including the value of the time interval can be used.

In the second mode, the verifier of the ticket may not need to execute a search algorithm

Third mode

All members of group G _i can generate a hash tree. The leaf nodes of the hash tree may be index values from the index vector V.

FIG. 10 shows a binary hash tree of an index vector according to an example.

The index vector V may be expressed by Equation (17) below.

BS _j may add index values V _i and hash values to the end of T _k . The hash values are log ₂ | V | .

These hash values may be selected nodes in the hash tree. An index search having a complexity of O (1) can be performed by hash values. Similarly, a hash tree reconstruction having a complexity of O (log) can be performed. At this time, the hash operations are all log ₂ | V |

 The algorithm of the index search may be the same as the following 1) to 5).

1) The index search may start from the head node. The index search may proceed from the head node toward the lower node.

2) The append value can be ignored and the search can proceed along the rebuilt node.

3) The search is at level log ₂ | V | -1.

4) Now, at the last level, the added value which is the index value can be selected.

The second mode may be suitable if the chain of keys is very long.

H _head can be the head node of the hash tree. The head node may optionally be included in T _k . The head node can ensure that T _k is generated from a trusted group member.

Managing the "chain of keys chain" at the sink node

11 illustrates management of a generator of a chain of keys in a sink node according to an example.

In order to spread the workload reissuing the ticket and session key, the sink node may keep a history of the chains of previous keys and may be able to keep track of the tickets and / The session key can be issued.

In Fig. 11, it is shown how a sink node spreads workload throughout a chain when using a chain of keys of length three. This spreading may be performed by adopting a moving window approach and may be performed by updating the ticket and session keys on a per interval basis.

The unfolding of the workload may include the following four steps.

Step 1) The sink node may discard the chain C ₀ of the previous keys. The sink node may generate a commitment key generator G ₀ ^j for the chain C ₁ of the following keys.

Step 2) At the first time interval l ₁ , the sink node may re-issue the ticket T _K ¹ and the session key to all authenticated sensor nodes.

Step 3) In the second time interval l _2, sink node re ticket T _K ^2, and the session key to all authenticated sensor node - may be issued.

Step 4) At the third time interval l ₃ , the sink node may re-issue the ticket T _K ³ and the session key to all authenticated sensor nodes. The sink node may discard the chain C ₁ of the previous keys and generate a commit key generator G ₀ ^j for the chain C ₂ of the following keys.

For example, the sink node may discard a chain of previous keys and generate a commit key generator for a chain of next keys whenever the time intervals of the length of the chain of keys have elapsed. For each time interval, the sink node may re-issue the ticket and session key to all authenticated sensors.

Authentication procedure

Sensor node N _i can be authenticated by the three different methods. When N _i joins the system, N _i may go through an initial authentication process. To move after the initial authentication, N _i is from one BS to another BS of BS _k the BS _j, N _i is a re-authentication ticket T _K - it can be authenticated.

In the following three different authentication schemes are described.

12 is a flowchart of an authentication procedure according to an example.

Step 620 described above with reference to FIG. 6 may include steps 1210, 1220, 1230, 1240, 1250, 1260, and 1270.

At step 1210, a request for sensor node N _i may be received.

If the sensor node N _i is the request to join request, the step 1220 or step 1280 can be performed.

If the sensor node N _i of the request of the request to join the sensor node, it can be performed step 1220.

If the request of sensor node N _i is a subscription request of the user, step 1280 may be performed.

Sensor node N _i is not the request of the subscription request, the step 1230 or step 1235 can be performed.

Step 1230 can be performed if the request of the sensor node N _i is a request of the switch and a request for multiple connections.

Step 1235 may be performed if the request of the sensor node N _i is a request of the switch and a request for node mobility.

At step 1220, a Sensor Activation and Authentication Protocol (SAAP) may be performed.

In step 1230, if S _k and S _j are members of G _i , step 1240 may be performed. If S _k and S _j are not members of G _i , step 1250 may be performed.

In step 1235, if S _k and S _j are members of G _i , step 1240 may be performed. If S _k and S _j are not members of G _i , step 1260 can be performed.

In step 1240, a Sensor Re-Authentication Protocol 1 (SRP1) may be performed.

In step 1250, if S _j is within the range of N _i and S _j is a member of G _k ⁰ , then step 1270 may be performed. If S _j is not in the range of N _i , or if S _j is not a member of G _k ^{0, then} the procedure may end.

In step (1260), has N _i can be moved to and S _j, S _j is not a member of the G _k ^0, step 1270 is performed. If N _i does not move to S _j , or if S _j is a member of G _k ⁰ , then the procedure may end.

In step 1270, a Sensor Re-Authentication Protocol 2 (SRP2) may be performed.

In step 1280, either step 1285, step 1290, or step 1295 may be performed depending on the subscription type of the user's subscription request. If the subscription type is "user-base station ", step 1285 may be performed. If the subscription type is "user-sync ", step 1290 may be performed. If the subscription type is "user-sensor ", step 1295 may be performed.

At step 1285, a User Activation and Authentication Protocol (UAAP) may be performed.

In step 1290, a User-Sink Authentication Protocol (USiAP) may be performed.

In step 1295, a User-Sensor Authentication Protocol (USEAP) may be performed.

SAAP

13 is a flowchart of SAAP according to an example.

Step 1220 described above with reference to FIG. 12 may include the following steps 1310, 1320, 1330, 1340, 1350, and 1360.

The sink node S _j may periodically broadcast a hello message with the public key of BS _j .

The hello message can be defined as Equation (18) below.

If N _i wants to join the WSN, N _i can generate an encryption key K _TS ⁱ by hearing the hello message. The encryption key K _TS ⁱ can be defined as: " (19) "

N _i can encrypt the subscription message with the generated encryption key K _TS ⁱ and the following steps 1310, 1320, 1330, 1340, 1350 and 1360 can proceed.

In step 1310, if N _i receives a hello message, N _i may transmit the first message to sink node S _j . The first message may be a subscription message. A request for a service via the first message may be sent from N _i to S _j .

The first message may include information of Equation (20) below.

n ₀ may be a nonce determined by N _i .

Through the first message, N _i may transmit N ₀ encrypted with the generated encryption key K _TS ⁱ as S _j .

In step 1320, upon receipt of the request from N _i , S _j may send a second message for the first message to BS _j . Through the second message, the request of N _i may be delivered to BS _j via S _j .

The second message may include information of Equation (21) below.

" M 1" may be the first message described above.

Via a second message, S _j can transmit a request from the N _i associated with the identifier and the challenge of n ₂ S _j by BS _j.

In step 1330, when BS _j receives the second message, BS _j may extract the profile of N _i from the database using the identifier of N _i in the second message.

If N _i is a legitimate sensor node, BS _j can generate key K _TS ⁱ . The key K _TS ⁱ can be defined as: < EMI ID = 22.0 >

BS _j may transmit the third message S _j .

The third message may include the information of Equation 23 below.

BS _j may transmit u ₀ , which is intended for N _i , to S _j . In addition, BS _j may transmit the ticket T _k S _j to S _j intended for. Ticket T _k can be encrypted with the group key K _G ^j of the group of BS _j.

The third message may contain u ₀ . u ₀ can be defined as Equation (24) below.

T _K may be a ticket based on time.

T _R can be the valid time for K _S ⁱ .

T _R may be a validity time for K _S ^k . T _R can be defined as: " (25) "

l _i may be the system time during the i < th > time interval during which the ticket and session key were issued. L may be the time duration of the keychain.

In addition, the third message may include a ticket T _k, n ₁ and Maintenance maintenance n _2. All of the ticket T _k, nonce n ₁ n ₂ and the nonce may be encrypted with K _G ^j.

n ₁ may be a nonnegative determined by BS _j . n ₁ may be a challenge for N _i .

n ₂ may be the response to the challenge of the sink node S _j .

T _K may be a ticket based on time.

As defined in equations (14), (15) and (16), T _k may include the information of Equation (26) below.

" Prof " can represent the profile of N _i .

If the third message is sent to sink node S _i , S _j can verify for challenge n 2 and store n 1.

Also, when the third message is transmitted to the sink node S _i , S _j can extract the profile of N _i and K _s ⁱ from the information of T _k .

In step 1340, S _j may transmit the fourth message as N _i . The fourth message may include information of Equation (27) below.

The fourth message may be a response to the first message at step 1310. [ Also, u ₀ of the fourth message may include information of a ticket T _k issued from BS _j .

S _j can carry u ₀ as N _i .

The first message at step 1310 and the second message at step 1320 may include n ₀ . Also, u ₀ of the third message in step 1330 and the fourth message in step 1340 may include n ₀ +1. Thus, the first message at step 1310 and the second message at step 1330 may be a challenge, and the third message at step 1330 and the fourth message at step 1340 may be for a challenge Response.

N _i can use n ₀ +1 to verify the challenge. After verification of the challenge, N _i may accept T _k and begin transmitting data to S _j .

The fourth message may include information of the ticket T _k issued from the BS _j to perform authentication with N _i, N _i is the material after - T _k can be used in authentication.

In step 1350, S _j may send a fifth message, which is a response to the third message, to BS _j .

The fifth message may include information of Equation (28) below.

The third message in step 1330 may include n ₁ . The fifth message may include n ₁ +1. Thus, the fifth message may be a response to the challenge of the third message at step 1330. [ S _j may send ( n ₁ +1), a response to the challenge, to BS _j as an acknowledgment of a successful protocol run.

In step 1360, N _i may send a sixth message, S _j , which is a response to the fourth message.

The sixth message may include information of Equation (29) below.

The fourth message in step 1340 may include n ₁ . The sixth message may include n ₁ +1. Thus, the sixth message may be a response to the challenge of the sixth message at step 1340. [

S _j can use n ₁ +1 to confirm the challenge. After confirmation of the challenge, S _j may begin receiving sensor data. If no confirmation is made for the challenge, S _j can mark T _k as a void ticket.

In SAAP, a secure exchange of n ₀ can guarantee message authentication between the sensor node and the base station. A secure exchange of n ₂ can ensure message authentication between the sink node and the base station. A secure exchange of n ₁ can ensure message authentication between the sensor node and the sink node. In addition, message authentication between the sensor node and the sink node may be established by session key encryption and n ₁ . If N _i is already registered in BS _j at step 1310, then n ₀ may be replaced with a hash of the cipher value.

SRP1

14 is a flow chart of the SRP 1 according to an example.

Step 1240 described above with reference to FIG. 12 may include the following steps 1410, 1420, and 1430.

If sensor node N _i wishes to establish multiple secure connections with sinks S _j , SRP 1 may be performed as follows. At this time, S _j may be a member of G _i .

Alternatively, if N _i moves from S _k to S _j and S _k and S _j hold, then the first case of re-authentication may be performed.

S _k and S _j may be members of G _i .

In step 1410, N _i may transmit the first message Switch _Req to S _j . The first message may be a message requesting a switch.

" Switch _Req " may indicate that the first message transmitted is a message requesting establishment of a connection with sink node S _j .

The first message may be constructed as shown in Equation (31) below.

n ₀ may be a nonce determined by N _i .

S _j can extract the ticket T _k from the first message.

The first message is a re-N _i - may include information T _k for authentication.

As defined in Equations (14), (15) and (16), T _k may include information of K _s ⁱ . S _j can decode T _k . Through decryption, S _j can extract K _s ⁱ . In addition, S _j may be calculated hash value for the n ₀ ^i, it can be compared with the hash value H (n ₀ ⁱ⁾ received in the message switch. If the hash value and the value of H ( n ₀ ⁱ ) do not match, S _j can ignore the request. Otherwise, proceed as described below.

In step 1420, S _j may transmit the second message as N _i in response to the first message. The second message may include information of Equation (32) below.

The second message may include N ₀ +1 information. Thus, the second message may be a response to the challenge of the first message at step 1410. [

n ₁ may be a nonnegative determined by S _j . The second message may be a new challenge for N _i . A new challenge for the N _i n ₁ session key may be encrypted with K ⁱ _s.

In step 1430, N _i may send a third message, S _j , which is a response to the second message.

The third message may include the information of Equation 33 below.

The second message in step 1420 may include n ₁ . The third message may include n ₁ +1. Thus, the third message may be a response to the challenge of the second message at step 1420. [

S _j can use n ₁ +1 to confirm the challenge. After confirmation of the challenge, S _j may begin to receive the data. If no confirmation is made for the challenge, S _j can mark T _k as a void ticket.

In SRP1, n ₀ ⁱ can guarantee message authentication between the sensor node and the sink node. With this feature, the sensor node can establish multiple secure sessions with the various sink nodes shown in FIG.

SRP2

15 is a flow chart of SRP2 according to an example.

Step 1270 described above with reference to FIG. 12 may include the following steps 1510, 1520, 1530, 1540, 1550, and 1560.

If the sensor node N _i wants to establish another secure connection with the sink node S _j , the following SRP 2 can be performed. For S _j , Equation (34) below can be established.

Alternatively, when the sensor node N _i moves from S _k to S _j , the following SRP 2 can be performed. For S _j , Equation (34) below can be established.

The re-authentication procedure may proceed as follows.

In step 1510, N _i may transmit the first message Switch _Req to S _j . The first message may be a message requesting a switch.

" Switch _Req " may indicate that the first message transmitted is a message requesting establishment of a connection with sink node S _j .

The first message may be configured as shown in Equation (35).

n ₀ may be a nonce determined by N _i .

The first message is a re-N _i - may include information T _k for authentication.

When S _i receives the first message, S _j can extract the ticket T _k from the first message.

S _j can decode the second part, which is the second half of T _k . S _j may use the decrypted second portion of T _k to check the identities of N _i and the base station granting the ticket. For example, if the second part, arguments or information is not from N _i , then S _j may discard the request. If the second part, argument or information comes from N _i , then S _j can forward the Switch _Req to BS _j .

In step 1520, after checking for the catering, S _j may send a second message to BS _j . The second message may include information of Equation (36) below.

S _j can forward the Switch _Req to BS _j through the second message.

The second message may contain information of n ₂ . n ₂ may be a nonce determined by S _j .

The information of the second message may be encrypted with K _G ^j .

In step 1530, when BS _j receives the second message, BS _j may extract the profile of N _i from T _k .

If N _i is a legitimate sensor node, BS _j may generate an encryption key K _TS ⁱ . The encryption key K _TS ⁱ can be defined as Equation 37 below.

BS _j may transmit the third message S _j . The third message may include information of Equation (38) below.

n ₁ and n ₂ may be non-determinable by BS _j .

BS _j may transmit u ₀ ^new to S _j in the third message. u ₀ ^new may be intended for N _i . u ₀ ^new can be defined as shown in Equation 39 below.

In addition, the third message may include a ticket T _k, n ₁ and Maintenance maintenance n _2.

n ₁ may be a challenge for N _i . n ₂ may be a challenge response to S _j .

All of the ticket T _k, nonce n ₁ n ₂ and the nonce may be encrypted with K _G ^j.

The sink node S _j can verify the challenge n ₂ , store n ₁ , and extract K _s ⁱ from the ticket.

In step 1540, S _j may transmit the fourth message as N _i . The fourth message may include information of Equation 40 below.

S _j may transmit u ₀ ^new to N _i through the fourth message.

U ₀ ^new of the fourth message may include N ₀ +1. Thus, the third message at step 1530 and the fourth message at step 1540 may be a response to a challenge of the first message at step 1510 and the second message at step 1520.

N _i can use n ₀ +1 to verify the challenge. After verification of the challenge, N _i may accept T _k and begin transmitting data to S _j .

In step 1550, S _j may send a fifth message, which is a response to the third message, to BS _j .

The fifth message may include the information of Equation 41 below.

The third message at step 1530 may include n ₁ . The fifth message may include n ₁ +1. S _j may send ( n ₁ +1), a response to the challenge, to BS _j as an acknowledgment of a successful protocol run.

At step 1560, N _i may send a sixth message, S _j , which is a response to the fourth message.

The sixth message may include information of Equation 42 below.

The fourth message at step 1540 may include n ₁ . The sixth message may include n ₁ +1. Thus, the sixth message may be a response to the challenge of the sixth message at step 1540. [

S _j can use n ₁ +1 to confirm the challenge. After confirmation of the challenge, S _j may begin to receive the data. If no confirmation is made for the challenge, S _j can mark T _k as a void ticket.

In SRP2, a secure exchange of n ₀ ⁱ can guarantee message authentication between the sensor node and the base station. A secure exchange of n ₂ can ensure message authentication between the sink node and the base station. A secure exchange of n ₁ can ensure message authentication between the sensor node and the sink node. In addition, message authentication between the sensor node and the sink node may be established by session key encryption and n ₁ .

If N _i wants to share data in a secret mode, both N _j and S _j can generate a private session key K _sp ^j . Session key K _sp ^j may be defined as shown in Equation 43 below.

With this characteristic, the sensor node can establish multiple secure sessions with various sink nodes as shown in FIG.

UAAP

In some scenarios, the user may want to access data from the sensor network. For example, within IoT applications such as smart home, building, and city, a user of a smartphone may want to acquire the data of the sensor node.

The user may request to access the data directly from the sensor node and may want to collect it from the sink node. In either case, the first user node U _i may request the authentication of the user node U _i itself to BS _j .

BS _j may be able to extract a profile of U _i, it can be marked with an activated (active) of the user U _i. The structure of the ticket of U _i may be the same as the structure of the ticket described in the previous embodiments for N _i . The information of the user profile may include the user's allowed accessibility information in collecting data.

In UAAP, a user may acquire tickets from BS _{j in} two different ways. If the user is not within the communication range of BS _j , the user may route the subscription message to the nearest sink node S _j . In this respect, UAAP can proceed in the same way as SAAP. However, if the user is within range of the BS _j, the user U _i may encrypt the association message to the encryption key, it is possible to generate a _TS K ^i, the generated encryption key K _TS ^i. The encryption key K _TS ⁱ can be defined as shown in Equation (44) below.

Next, the UAAP can proceed as follows and FIG.

16 is a flow diagram of a UAAP according to an example.

In FIG. 16, a message exchange in UAAP is shown.

Step 1285 described above with reference to FIG. 12 may include the following steps 1610, 1620, and 1630.

In step 1610, U _i may transmit the first message to BS _j . The first message may be a subscription message.

The first message may include information of Equation (45) below.

The first message may include n ₀ and the identity of the user.

In step 1620, BS _j may extract the profile of U _i from the database. If U _i is a legitimate user, then BS _j can send a second message to U _i .

The first message may include the information of Equation 46 below.

S _j may generate an authentication ticket T _k, T _k may transmit the authentication ticket with a nonce n ₁ n _0, and maintenance.

n ₁ may be a challenge to U ₁ .

n ₀ may be a response to the challenge.

Both the authentication ticket T _k , the nonsense n ₁ and the nons n ₀ can be encrypted with the encryption key K _TS ⁱ . The encryption key K _TS ⁱ can be defined as the following equation (47).

Structure of the authentication ticket T _k is, is can be the same as the authentication ticket is described in the previous embodiment except that the authentication ticket T _k nonce n ₁ of the (enclosed) secret enclosed within that produced by the BS _j.

In step 1630, the user node U _i can verify the challenge n ₀ and store T _k and n ₁ .

U _i may send a third message to BS _j , which is a response to the second message.

The third message may include information of Equation (48) below.

U _i can send a response to the challenge n ₁ +1 to BS _j . n ₁ +1 can confirm the successful implementation of the protocol.

After receiving the response n ₁ +1 to the challenge, BS _j may update the state of U _i from idle to active user.

In UAAP, a secure exchange of n ₀ can guarantee message authentication between the user node and the base station. A secure exchange of n ₁ can ensure message authentication between the base station and the user node.

USiAP

The above-described step 1290 in Fig. 12 may be performed as follows.

After obtaining the authentication ticket, if the user U _k wants to access data from the sink nodes S _j , the user U _k may send the join request with S _j to the S _j . Next, the same procedure as SRP1 and SRP2 described above with reference to Figures 14 and 15, except that S _j can piggyback data with the rest of the messages after verification for the ticket, is performed .

Using the authentication ticket, the user U _k can establish multiple concurrent connections with various sink nodes.

USeAP

U _k can request U _k own authentication to N _i to collect data directly from the sensor node.

U _k can transmit the ticket as N _i . N _i can forward the request of U _k to sink node S _j . S _j can decrypt the ticket, and K _s ⁱ can be extracted by decoding the ticket.

USeAP can proceed as shown in FIG. 17 below.

17 is a flow chart of USeAP according to an example.

In FIG. 17, a message exchange for user authentication at the sensor node is shown.

Step 1295 described above with reference to FIG. 12 may include the following steps 1710, 1720, 1730, and 1740.

In step 1710, U _k may transmit the first message N _i .

The first message may include information of Equation 49 below.

The first message may include a ticket T _k and a challenge n ₀ . The ticket T _k and the challenge n ₀ can be encrypted with the session key centered on the ticket.

U _k can transmit a ticket T _k encrypted with the session key centered on the ticket and the challenge n ₀ as N _i .

The first message may be a data collection request.

In step 1720, upon receipt of the data collection request from U _k , N _i may transmit the second message to sink node S _j .

The second message may include the information of Equation 50 below.

The second message may include an encrypted challenge n _1.

Upon receiving the data collection request from U _k , N _i may send the ticket and encrypted challenge n ₁ to sink node S _j .

At step 1730, the sink node S _j can decrypt the ticket and extract the session key K _S ^k of U _k by decrypting the ticket.

If U _k is a legitimate user node, S _j may transmit the third message N _i .

The third message may include information of Equation (51) below.

The third message may include ( N ₁ +1) which is a response to the challenge of step 1720.

S _j may transmit K _S ^k and a response to the challenge ( n ₁ +1) as N _i .

In step 1740, N _i may perform verification for the challenge.

N _i may extract ( n ₁ +1) from the third message transmitted in step 1730 and perform verification of the challenge transmitted by N _i .

After verification for the challenge, N _i may generate a private session key K _ps ^k . The private session key K _ps ^k can be defined as Equation 52 below.

N _i may transmit the fourth message to U _k .

The fourth message may include information of Equation (53) below.

The fourth message may include ( n ₀ +1). ( n ₀ +1) may be a response to the challenge at step 410.

N _i may send a response ( n ₀ +1) to the challenge encrypted with the private session key K _ps ^k as U _k .

If the fourth message is sent, U _k may generate a private session key ^k K _ps, can decrypt the fourth message by using the private session key ^k K _ps. U _k can verify the challenge by extracting ( n ₀ +1) from the decrypted fourth message.

In USeAP, a secure exchange of n ₀ can guarantee message authentication between a user and a sensor node. A secure exchange of n ₁ can ensure message authentication between the sensor node and the sink node.

The apparatus described above may be implemented as a hardware component, a software component, and / or a combination of hardware components and software components. For example, the apparatus and components described in the embodiments may be implemented within a computer system, such as, for example, a processor, a controller, an arithmetic logic unit (ALU), a digital signal processor, a microcomputer, a field programmable array (FPA) A programmable logic unit (PLU), a microprocessor, or any other device capable of executing and responding to instructions. The processing device may execute an operating system (OS) and one or more software applications running on the operating system. The processing device may also access, store, manipulate, process, and generate data in response to execution of the software. For ease of understanding, the processing apparatus may be described as being used singly, but those skilled in the art will recognize that the processing apparatus may have a plurality of processing elements and / As shown in FIG. For example, the processing unit may comprise a plurality of processors or one processor and one controller. Other processing configurations are also possible, such as a parallel processor.

The software may include a computer program, code, instructions, or a combination of one or more of the foregoing, and may be configured to configure the processing device to operate as desired or to process it collectively or collectively Device can be commanded. The software and / or data may be in the form of any type of machine, component, physical device, virtual equipment, computer storage media, or device , Or may be permanently or temporarily embodied in a transmitted signal wave. The software may be distributed over a networked computer system and stored or executed in a distributed manner. The software and data may be stored on one or more computer readable recording media.

The method according to an embodiment may be implemented in the form of a program command that can be executed through various computer means and recorded in a computer-readable medium. The computer-readable medium may include program instructions, data files, data structures, and the like, alone or in combination. The program instructions to be recorded on the medium may be those specially designed and configured for the embodiments or may be available to those skilled in the art of computer software. Examples of computer-readable media include magnetic media such as hard disks, floppy disks and magnetic tape; optical media such as CD-ROMs and DVDs; magnetic media such as floppy disks; Magneto-optical media, and hardware devices specifically configured to store and execute program instructions such as ROM, RAM, flash memory, and the like. Examples of program instructions include machine language code such as those produced by a compiler, as well as high-level language code that can be executed by a computer using an interpreter or the like. The hardware devices described above may be configured to operate as one or more software modules to perform the operations of the embodiments, and vice versa.

  While the present invention has been particularly shown and described with reference to exemplary embodiments thereof, it is to be understood that the invention is not limited to the disclosed exemplary embodiments. For example, it is to be understood that the techniques described may be performed in a different order than the described methods, and / or that components of the described systems, structures, devices, circuits, Lt; / RTI > or equivalents, even if it is replaced or replaced.

100: Sensor network
200: Base station
300: sink node
400: sensor node

Claims (1)

The base station of the sensor network,
Generating a chain of keys for authentication to a communication entity within the network; And
Performing authentication on the sensor node based on the chain of keys
Lt; / RTI >
Wherein each key of the chain of keys is valid in a predetermined time interval for each key.

Images