KR102032032B1 - Dtls based end-to-end security method for internet of things device - Google Patents

Abstract

The method for secure operation of an IoT device may include requesting a security proxy to issue a certificate for itself; Receiving a certificate and a signature from the security proxy and deriving its private and public keys using the certificate and signature and the public key of the security proxy; And performing an initial DTLS handshake with the client based on the certificate and the client's public key. In addition, the client may be provided with a client's pre-shared key (PSK) token to be used in a subsequent DTLS handshake between the client and another IoT device belonging to the same group as the IoT device during the initial DTLS handshake.

Description

DTLS-based END-TO-END SECURITY METHOD FOR INTERNET OF THINGS DEVICE}

The present invention relates to a method for providing security between an IoT device and a client, and more particularly, to end-to-end based on datagram transport layer security (DTLS) in consideration of asymmetric performance between the IoT device and a client device. -to-end) on how to provide security.

As interest in the Internet of Thing (IoT) has increased, the spread has spread and the foundation products and services have been increasing rapidly. In particular, as the IoT operating environment is extended from the existing closed environment to the open environment, security of the IoT operating environment is increasing as it deals with sensitive information of individuals and organizations. In a traditional wireless sensor network (WSN) environment, there is a proxy that manages multiple sensor devices, and when a proxy collects sensor information, the remote client requests information from the proxy. Direct access to the sensor device was not allowed. Sensor layer and proxy require link layer security such as IEEE 802.15.4 security or ZigBee security, and network or transport layer security such as IPSEC (IPSEC) or transport layer security (TLS) between proxy and client. do. Therefore, seamless security does not apply between the client and the sensor device.

On the other hand, end-to-end security is essential for applications based on IoT network architecture. IPSEC and TLS cannot be used for end-to-end security because they are not suitable for resource-constrained sensor devices in terms of computation, memory, and power. Therefore, end-to-end security based on IoT network architecture requires a security protocol considering asymmetric performance between sensor device and client.

An object of the present invention for solving the above problems is to provide a secure operation method of the IoT device as a DTLS-based end-to-end security method in consideration of the asymmetric performance between the IoT device and the client in the IoT environment.

Another object of the present invention for solving the above problems is to provide a secure operation method of the client as a DTLS-based end-to-end security method, considering the asymmetric performance between the IoT device and the client in the IoT environment.

Another object of the present invention for solving the above problems is a DTLS-based end-to-end security method in consideration of the asymmetric performance between the IoT device and the client in the IoT environment, security for complementing the asymmetric performance of the IoT device and client It is to provide a security operation method of a proxy (SP).

The present invention for achieving the above object, the Internet of Things (IoT) devices belonging to the first group of at least one group, a client having access rights to the IoT devices belonging to the first group, and the IoT devices In an IoT environment including a security proxy (SP) existing between a client and the client, a security operation method of a first IoT device (S _x ) among the IoT devices may include requesting issuance of a certificate for the SP. step; Receiving a certificate and a signature from the SP and deriving its own private and public key using the certificate and signature and the public key of the SP; And performing an initial DTLS handshake with the client based on the certificate and the public key of the client. In the initial DTLS handshake process, a PSK (pre-shared key) token of the client to be used in a subsequent DTLS handshake between another IoT device belonging to the first group and the client may be provided to the client.

According to another aspect of the present invention, there is provided an Internet of Things (IoT) devices belonging to a first group of at least one group, a client having access to IoT devices belonging to the first group, and the IoT device. In a IoT environment including a security proxy (SP) existing between the client and the client, a method of operating the client, the capability ID instructing the SP to access the IoT devices belonging to the first group Requesting issuance of a and receiving the capability ID; And performing an initial DTLS handshake based on a certificate of the first IoT device and the first IoT device among the IoT devices belonging to the first group and the public key of the client. In addition, a PSK token of the client to be used in a subsequent DTLS handshake between another IoT device belonging to the first group and the client during the initial DTLS handshake may be provided from the first IoT device. .

According to another aspect of the present invention, there is provided an Internet of Things (IoT) devices belonging to a first group of at least one group, a client having access to IoT devices belonging to the first group, and the IoT. In an IoT environment including a security proxy (SP) existing between devices and the client, an operation method of the SP includes receiving a certificate issuance request for the first IoT device from the client, and receiving the first IoT device from the client. Sending the issued certificate and signature to the device; And receiving a request for issuing a capability ID indicating the access right to IoT devices belonging to the first group to the SP and delivering the issued capability ID.

Embodiments according to the present invention proposed a DTLS-based group-oriented end-to-end security method for secure CoAP applications. During the end-to-end secure connection between the CoAP server (i.e. IoT device) and the client, the PSK token is issued at the end of the initial DTLS handshake to reduce the computational amount by the DTLS handshake. The PSK mode was used to reduce the amount of computation caused by the DTLS handshake.

In addition, based on the concept of capability ID, IoT devices are grouped in advance to enable fine-grained access control. As a result, various IoT applications can securely take advantage of group-oriented end-to-end security. Indirect approaches to sensor devices via proxies used in traditional wireless sensor networks could not achieve complete end-to-end security because only the server and client share key information, but according to embodiments of the present invention, the proxy may Only access control information is known and sensitive information such as key information meets end-to-end security that is shared only between the server and client.

1 is a conceptual diagram illustrating a basic principle of an DTLS-based end-to-end security method according to an embodiment of the present invention and an IoT environment to which it is applied.
2 is a conceptual diagram illustrating a configuration example of a capability list as an access control list in a DTLS-based end-to-end security method according to an embodiment of the present invention.
FIG. 3 is a conceptual diagram illustrating a configuration of a DTLS message used in a DTLS-based end security method according to an embodiment of the present invention.
4 is a flowchart illustrating an aspect in which a DTLS-based end-to-end security method is performed in an IoT device according to an embodiment of the present invention.
5 is a flowchart illustrating an aspect in which a DTLS-based end-to-end security method is performed in a client according to an embodiment of the present invention.
6 is a flowchart illustrating an aspect in which a DTLS-based end-to-end security method is performed in an SP according to an embodiment of the present invention.
7 is a graph showing the results of measuring DTLS handshake delay time in PSK, RPK, certificate (ECDSA-equipped X.509 certificate and ECQV certificate) mode together with the proposed protocol.
8 is a graph illustrating a result of measuring DTLS handshake round trip delay for each security mode on a 6LoWPAN network.

As the invention allows for various changes and numerous embodiments, particular embodiments will be illustrated in the drawings and described in detail in the written description. However, this is not intended to limit the present invention to specific embodiments, it should be understood to include all modifications, equivalents, and substitutes included in the spirit and scope of the present invention. In describing the drawings, similar reference numerals are used for similar elements.

Terms such as first, second, A, and B may be used to describe various components, but the components should not be limited by the terms. The terms are used only 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 the second component, and similarly, the second component may also be referred to as the first component. The term and / or includes a combination of a plurality of related items or any item of a plurality of related items.

When a component is referred to as being "connected" or "connected" to another component, it may be directly connected to or connected to that other component, but it may be understood that other components may be present in between. Should be. On the other hand, when a component is said to be "directly connected" or "directly connected" to another component, it should be understood that there is no other component in between.

The terminology used herein is for the purpose of describing particular example embodiments only and is not intended to be limiting of the present invention. Singular expressions include plural expressions unless the context clearly indicates otherwise. In this application, the terms "comprise" or "have" are intended to indicate that there is a feature, number, step, operation, component, part, or combination thereof described in the specification, and one or more other features. It is to be understood that the present invention does not exclude the possibility of the presence or the addition of numbers, steps, operations, components, components, or a combination thereof.

Unless defined otherwise, all terms used herein, including technical or scientific terms, have the same meaning as commonly understood by one of ordinary skill in the art. Terms such as those defined in the commonly used dictionaries should be construed as having meanings consistent with the meanings in the context of the related art and shall not be construed in ideal or excessively formal meanings unless expressly defined in this application. Do not.

Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings.

Datagram transport layer security (DTLS) serves as a defacto standard for IoT security that can complement the problem of end-to-end asymmetric performance. The IoT's application layer protocol, CoAP (constrained application protocol), defines three security modes, including pre-shared key (PSK), raw public key (RPK), and certificate mode. Each security mode has advantages and disadvantages.

First of all, PSK mode has advantages in terms of performance, but as more IoT devices (ie, CoAP servers) and more clients (ie, CoAP clients) connect to IoT devices, it is not easy to deploy unique symmetric keys in advance.

On the other hand, RPK and certificate modes require ECDSA (EC-Digital Signature Algorithm) operation, so the computational load on IoT devices is relatively higher than that of PSK security mode. However, the key management is relatively easy due to the public key infrastructure (PKI). Certificates used in certificate mode have high compatibility and extensibility because they conform to X.509, but they are not suitable in IoT environments where resource-constrained IoT devices are utilized because of their large size and relatively high computational load. As a result, it is advantageous to utilize an elliptic curve-based Elliptic Curve Qu-Vanstone (ECQV), which is a smaller implicit certificate than a traditional certificate.

In an embodiment according to the present invention, CoAP client considers group-oriented end-to-end security that can access CoAP servers in a pre-assigned group. Technical features of one embodiment according to the present invention to be described below are as follows. Each technical feature is explained in full detail.

First, establish a secure connection between the CoAP client and the CoAP server group. To do this, the CoAP server and client use ECQV certificates and authenticated RPKs, respectively.

Second, the DTLS handshake procedure is performed by dividing the initial DTLS handshake and the subsequent DTLS handshake to reduce the total calculation amount due to the DTLS handshake. The 'Initial DTLS Handshake' is performed with one of the IoT devices belonging to a group to which the client has access rights, and the PSK key to be used for IoT devices belonging to the group and subsequent DTLS handshakes in the initial DTLS handshake procedure. Is issued. Thus, subsequent DTLS handshakes with other IoT devices in the same group proceed in PSK mode.

Third, the concept of 'capability ID' issued by Security Proxy (SP) to CoAP clients to embed fine-grained access control for CoAP servers in the same group. Introduce.

Normally DTLS Handshake  process

Prior to describing a DTLS-based end-to-end security method according to an embodiment of the present invention, a general DTLS handshake process will first be briefly described.

The DTLS handshake process consists of security negotiation, key exchange, and key confirmation steps. First, in the security negotiation stage, a security mode and a cipher suit are determined, and additionally, a nonce is exchanged. According to the security mode, an authentication key (AK) called 'Pre-Master Secret' is derived and a session key (SK) called 'Master Secret' is derived using AK and Nonce in the key exchange step. Finally, CoAP server and client perform mutual authentication based on SK through key verification step.

In the PSK mode of DTLS, a CoAP server maintains an access control list with a PSK shared with CoAP clients that will communicate with it. Therefore, in the PSK mode, in order to start the DTLS handshake, the symmetric key should be provided to the CoAP server and the authorized client in a separate manner. CoAP server and client in RPK mode maintain ECDSA public key / private key pair, respectively, and must obtain each other's public key through separate method like PSK mode. In this way, the CoAP server can also construct access control lists for authorized clients and their public keys.

Mutual authentication in the key verification phase is performed on the basis of ECDSA. Finally, in certificate mode, X.509 certificates based on ECDSA are used, and CoAP servers and clients use X.509 certificates with ECDSA public / private key pairs.

1 is a conceptual diagram illustrating a basic principle of an DTLS-based end-to-end security method according to an embodiment of the present invention and an IoT environment to which it is applied.

1, the IoT environment to which the DTLS-based end-to-end access control method according to an embodiment of the present invention is applied, a plurality of IoT devices (that is, each of the CoAP server, S ₁ , S ₂ , S ₃ , ..., S ₇ ), which may be a low-power wireless personal area network (LoWPAN) network (100), connected to the IPv6 Internet through a 6LowPAN border router (6LBR), and a client over the IPv6 Internet (C _A , 130).

Here, IoT devices are grouped into at least one subgroup (Sub _j , j = 1, 2, ..., k), and a specific IoT device belongs to only one subgroup. IoT devices belonging to a specific subgroup share the same group key GK _i and a security proxy (SP, 120) manages sensor devices (S _i , i = 1, 2, ...) in LoWPAN Assume that you share a symmetric key (K _i ) with the devices. Meanwhile, in FIG. 1, although the 6LBR 110 and the SP 120 are illustrated as separate components, the 6LBR 110 and the SP 120 may be configured as the same component.

Hereinafter, (1) a certificate issuance procedure performed between the SP 120 and respective IoT devices, which constitutes a DTLS-based end-to-end security method according to an embodiment of the present invention, and (2) SP 120 and Procedure for issuing access control information including a capability list and a capability ID performed between the client 130 and (3) an initial operation performed with the client 130 and one IoT device belonging to the group (eg, S ₁ ). DTLS handshake procedures, and (4) subsequent DTLS handshake procedures performed with the client 130 and other IoT devices in the group.

Certificate Issuance Procedure

First, each IoT device is issued an ECQV certificate for exchanging an elliptic curve Diffie-Hellman (ECDH) key with the client 130, where the SP 120 serves as a certificate authority (CA) that issues an ECQV certificate. Will be performed.

를 만족하는 포인트들의 집합이다. 타원곡선 매개변수는 (p,a,b,G,n)으로 표기하며, G는 차수가

인 베이스 포인트이다. IoT 디바이스에 대한 ECQV 인증서 발급은 다음과 같이 진행될 수 있다. IoT 디바이스(S_x)는 SP(120)에게 인증서를 요청하기 위해

을 생성하며

를 SP(120)에게 전송한다. 이에 응답하여, SP(120)는

를 생성하며, 하기 수학식 1과 같이 S_x의 암시적 인증서(Cert_x) 및 암시적 서명(s)을 생성할 수 있다.Elliptic curve E (F _p ) is on finite body E _p (p is prime)

Is a set of points satisfying. Elliptic curve parameters are denoted by (p, a, b, G, n), where G is the degree

Is the base point. Issuance of an ECQV certificate for an IoT device may proceed as follows. IoT device (S _x ) to request a certificate from the SP (120)

Generates

To the SP 120. In response, the SP 120

And generate an implicit certificate (Cert _x ) and an implicit signature (s) of S _x , as shown in Equation 1 below.

와 ECDH 공개키

를 도출할 수 있다. IoT 디바이스(S_x)의 공개키는 ECQV 인증서와 SP(120)의 공개키 Q_SP만 주어진다면 하기 수학식 2와 같이 도출이 가능하다.Upon receiving the certificate (Cert _x ) and signature (s) from the SP 120, the IoT device (S _x ) based on the received certificate and signature, the ECDH private key ECDH private key

And ECDH public keys

Can be derived. The public key of the IoT device S _x may be derived as shown in Equation 2 below if only the ECQV certificate and the public key Q _SP of the SP 120 are given.

Issuance of access control information

SP (120) may perform access control server for the client (C _A). That is, the authorized client C _A is assigned a specific subgroup to which the IoT devices to which access is allowed are assigned, and only access to IoT devices belonging thereto is allowed. In particular, depending on the role of the client it may further limit the IoT devices that are allowed to access in the assigned subgroup. In FIG. 1, four IoT devices S ₁ , S ₂ , S ₃ , and S ₄ are among IoT devices S ₁ , S ₂ , S ₃ , S ₄ , and S ₅ belonging to a subgroup Sub ₁ . for a group of which, it is assumed that access is possible, the client (C _a).

As such, the list of IoT devices accessible to the client C _A (ie, an access control list) may be defined as a 'capability list (CL _A )' of the client C _A. In addition, the SP 120 may issue a capability ID (capability I, capID _A ) corresponding to the capability list CL _A of the client C _A.

)을 가지고 있다고 가정할 때, 클라이언트(C_A)는 자신의 캐퍼빌리티 리스트(CL_A)에 포함된 하나의 IoT 디바이스와의 '초기DTLS 핸드쉐이크'를 진행할 때에는 해당 IoT 디바이스의 ECQV 인증서 및 인증된 RPK 모드를 사용할 수 있다. 초기 DTLS 핸드쉐이크 과정에서 해당 IoT 디바이스는 PSK 토큰을 생성해서 클라이언트(C_A) 에게 발행할 수 있다. 클라이언트(C_A)는 캐퍼빌리티 리스트(CL_A)에 속한 다른 IoT 디바이스와의 '후속 DTLS 핸드쉐이크'에서는 초기 DTLS 핸드쉐이크 절차에서 발행된 PSK 토큰을 사용해서 센서 디바이스와 간의 핸드쉐이크 계산 복잡도를 줄일 수 있다. Client (C _A ) itself establishes an ECDH private and public key pair (

Assuming that the client C _A is initiating a 'initial DTLS handshake' with one IoT device included in its capability list (CL _A ), the ECQV certificate and authenticated RPK mode is available. During the initial DTLS handshake, the IoT device can generate and issue a PSK token to the client C _A. The client C _A uses the PSK token issued in the initial DTLS handshake procedure in the 'subsequent DTLS handshake' with another IoT device in the capability list CL _A to reduce the complexity of the handshake calculations between the sensor device and the sensor device. Can be.

Such a capability list and a capability ID may be configured as follows as an example.

As mentioned above, the authorized client C _A may access IoT devices that are allowed access according to the defined capability list CL _A. You can define a Merkle tree that becomes the root hash node to embed access control according to the capability list.

2 is a conceptual diagram illustrating a configuration example of a capability list as an access control list in a DTLS-based end-to-end security method according to an embodiment of the present invention.

Referring to FIG. 2, each leaf node on the tree may correspond to each IoT device constituting a capability list (CLA), through which a saturated binary tree may be defined. At this time, it can be defined by the Merkle tree algorithm 1 shown below which corresponds to the capper Stability list of clients (C _A).

[Algorithm 1]

Given S ₁ , S ₂ , ..., S _l

와

에 대해서

를 계산

Wow

about

Calculate

를 통해서 루트 해시 노드가 계산된다(

). Auth_A는 클라이언트(C_A)가 자신의 캐퍼빌리티 리스트(CL_A)에 속한 IoT 디바이스들에 대한 접근 권한이 있음을 지시하는 캐퍼빌리티 ID(CapID_A)를 구성하는데 사용된다. Subordinate hash nodes of a node in the path from the leaf node to the root hash node may be defined as subsidiary nodes (for example, in FIG. 2, the sub-diaries of h ₂₀ become h ₂₁ and h ₁₁ ). . At this time, Auth _A can be calculated through the leaf node and subordinate node nodes of the leaf node (if h ₂₀ is given, it can be calculated through h ₂₁ and h ₁₁ without starting from all leaf nodes). To do this, define the following function: From leaf node (Sx) and thus Subsidiary _x

The root hash node is computed through

). Auth _A is used to construct a Capability ID CapID _A indicating that the client C _A has access to IoT devices belonging to its Capability List CL _A.

For the issuance of the capper metastability ID it has the following protocol 1 as can be performed between SP (120) and the client (C _A, 130). In this case, the following protocol 1 may be assumed to be protected by TLS, but how the secure connection between the client and the SP is established is outside the scope of the present invention.

[Protocol 1]

According to protocol 1, the client C _A 130 generates its ECDH public / private key pair Q _A , q _A and sends the CA 120 (CA, Sx, QA) to the capability ID. You can request issuance. Herein, the IoT device S _{x corresponds} to an IoT device to which the client C _A first attempts to access among IoT devices (ie, IoT devices belonging to a capability list ₎ to which the client C _A has access. The SP 120 determines the capability list CL _A , which is a list of IoT devices allowed to the client C _A , and after checking whether the IoT device S _x belongs to the capability list CL _A , Create CapID _A = H (K _x , Q _A , Auth _A ) and send it to the client (C _A ). K _x is a symmetric key shared in advance between SP and S _x .

Initial DTLS Handshake

If the certificate is issued to the IoT device S _x by the certificate issuing procedure described above, and the capability ID is issued to the client C _A by the access control information issuing procedure, the IoT device S _x and the client C _An initial DTLS handshake process between _A ) is performed.

Assuming that the client CA first accesses the IoT device S _x included in the capability list CL _A , an 'initial DTLS handshake' (protocol 2) may be performed therebetween.

[Protocol 2]

Client (C _A) IoT device (S _x) receiving the generated random number (N _A) is N _A and likewise the own ECQV certificate Cert _x described in the issued earlier and a self-generated random number (N _x) certificate process client Send to (C _A ). After obtaining the ECDH public key Q _x of the IoT device S _x , the client C _A obtains an authentication key AK _A and a session key SK _A as shown in Equation 3 below. Can be derived.

와

를 계산하고 MIC(SK_A)의 무결성을 확인하게 된다.Sending the public key Q _A , capID _A , and subsidiary _x of the client C _A to the IoT device S _x can verify the integrity of the transmission message through the MIC (SK _A ). At this time, the IoT device (S _x ) side by the same operation

Wow

We calculate and verify the integrity of MIC (SK _A ).

의 도출을 통해 캐퍼빌리티 ID를 계산하고 클라이언트(C_A, 130)으로부터 수신한 캐퍼빌리티 ID와 동일한지 확인한다. 동일하다면 클라이언트(C_A)가 IoT 디바이스(S_x)에 접근할 수 있는 권한이 있다는 것이 확인된다. 마지막으로 후술될 '후속 DTLS 핸드쉐이크'에서 사용할 클라이언트(C_A)의 PSK 토큰(

)를 클라이언트(C_A)에게 전달한다.Also,

Through derivation of the capability ID is calculated and it is checked whether the same as the capability ID received from the client (C _A , 130). If it is the same, it is confirmed that the client C _A is authorized to access the IoT device S _x . Finally, the PSK for client token (C _A) used in the "subsequent DTLS handshake" to be described below (

) To the client (C _A ).

Meanwhile, Table 1 below is a description of symbols used in the description of Protocol 2 (initial DTLS handshake) and Protocol 3 (subsequent DTLS handshake) to be described later, and can be referred to in parallel with Protocol 2 and Protocol 3.

Subsequent DTLS Handshake

If the client C _A acquires a PSK token by performing an initial DTLS handshake procedure according to protocol 2 with the IoT device S _x , which is one of the IoT devices belonging to its capability list CL _A , the client Handshake (ie, subsequent DTLS handshake) between (C _A ) and other IoT devices belonging to the capability list CL _A may be performed in the PSK security mode based on the acquired PSK token.

[Protocol 3]

를 도출하고

와 Subsidiary_x'를 S_x'에게 전달한다. When the client (C _A ), which has completed the initial DTLS handshake, accesses another IoT device with access rights, a subsequent DTLS handshake is performed. Based on the interchanged random numbers and the authentication key

To derive

And Subsidiary _{x '} to S _x '.

를 계산하고 마지막 메시지의 전송을 통해 자신에 대한 인증을 수행하게 된다.S _x 'already knows GK _i because it belongs to the same subset as S _x . Therefore, S _x is proved that there is a permission to access the 'calculates the Auth _A and client (C _A) is equal and determine the Auth _A pskTK of _A, if _A is equal to C _x S was transmitted. S _x '' too

Calculate and authenticate yourself by sending the last message.

FIG. 3 is a conceptual diagram illustrating a configuration of a DTLS message used in a DTLS-based end security method according to an embodiment of the present invention.

Referring to FIG. 3, DTLS messages used in the present invention are composed of a total of six message freights 310 to 360, and by modifying the certificate message field 340-1, the certificate Cert _x and capID of S ₁ . _A is loaded and Subsidiary _x can be loaded in the clientKey exchange message field 350-1. Thereafter, the PSK token to be used when performing the subsequent subset of S _x 'and the subsequent DTLS handshake may be loaded in the NewSessionTicket field 360-1.

On the other hand, step (①; 310 ~ 330) in Figure 3 may be a security negotiation step, step (②; 340) may be a key exchange step, step (③; 350 ~ 460) may mean a key verification step.

4 to 6 are flowcharts for describing in detail a process of performing a DTLS-based end-to-end security method on an IoT device, a client, and an SP according to an embodiment of the present invention.

The methods described in FIGS. 4 to 6 assume an IoT environment composed of at least one group of IoT devices, at least one client, and an SP that mediates between them. Particularly, among the IoT devices belonging to the first group of the at least one group, the first IoT device and the at least one client have access rights to the first IoT device (that is, the first IoT device has its own right). The operation of the client (included in the capability list), the first IoT device and the security proxy (SP) to mediate the client is described.

4 is a flowchart illustrating an aspect in which a DTLS-based end-to-end security method is performed in an IoT device according to an embodiment of the present invention.

Referring to FIG. 4, in the above-described IoT environment, a first IoT device S _x of the IoT devices may first include requesting a SP to issue a certificate for itself (S410); Receiving a certificate and a signature from the SP and deriving its own private and public key using the certificate and the signature and the public key of the SP (S420); And performing an initial DTLS handshake with the client based on the certificate and the public key of the client (S430). In this case, the client may be provided with a PSK token of the client to be used in a subsequent DTLS handshake between another IoT device belonging to the first group and the client in the initial DTLS handshake process.

At this time, as described in the certificate issuing procedure, the certificate issued by the SP is an Elliptic Curve Qu-Vanstone (ECQV) -based certificate, and the signature is a second pre-image resistant hash function of the certificate. Can be generated based on the value of.

The initial DTLS handshake may further include receiving a random number N _A from the client; Delivering the certificate and a random number (N _x ) to the client; An authentication key derived from an existing client using the public key Q _A of the client, the capability ID of the client, a value for verifying the capability ID, and the certificate and the public key of the SP And receiving an integrity verification code of the session key; Computing an authentication key and a session key, confirming the calculated integrity of the authentication key and the session key by using the integrity verification code, and verifying the capability ID by using a value for verifying the capability ID. Confirming access rights for the first group of; And when the integrity and the access right are verified, forwarding the client's pre-shared key (PSK) token to be used in a subsequent DTLS handshake between another IoT device belonging to the first group and the client. It can be configured to include.

Meanwhile, the capability ID includes a root hash node, a public key of the client, and the SP defined in a Merkle tree in which each of IoT devices belonging to the first group is located in a leaf node. The value for verifying the capability ID generated by using a public key shared among the first IoT devices in advance may be a subsidiary node value of the first IoT device on the Merkle tree.

5 is a flowchart illustrating an aspect in which a DTLS-based end-to-end security method is performed in a client according to an embodiment of the present invention.

Referring to FIG. 5, in the above-described IoT environment, the method of operating the client requests the SP for issuance of a capability ID indicating an access right to IoT devices belonging to the first group and sets the capability ID. Receiving step (S510); And performing an initial DTLS handshake based on a certificate of the first IoT device and the first IoT device and the public key of the client, among the IoT devices belonging to the first group (S520). In this case, a pre-shared key (PSK) token of the client to be used in a subsequent DTLS handshake between another IoT device belonging to the first group and the client in the initial DTLS handshake process may be provided from the first IoT device. .

The certificate of the first IoT device is an elliptic curve Qu-Vanstone (ECQV) based certificate, and the signature may be generated based on a second pre-image resistant hash function value of the certificate.

The initial DTLS handshake comprises: passing a random number N _A to the first IoT device; Receiving the certificate and random number N _x from the first IoT device; _A public key (Q _A ) of the client, a capability ID of the client, a value for verifying the capability ID, and an authentication key and a session key derived using the certificate and the public key of the SP delivering an integrity verification code of a session key to the first IoT device; And the PSK of the client to be used in a subsequent DTLS handshake between another IoT device belonging to the first group and the client when the integrity of the authentication key and session key and the access authority indicated by the capability ID are confirmed. shared key) key may be received from the first IoT device.

The integrity of the authentication key and the session key confirms the integrity of the authentication key and the session key calculated by the first IoT device using the integrity verification code, and the access right uses a value for verifying the capability ID. By verifying the capability ID.

The capability ID is a root hash node value defined on a Merkle tree where each of IoT devices belonging to the first group is located in a leaf node, a public key of the client, and the SP and the SP. It may be generated using a public key shared in advance between first IoT devices, and a value for verifying the capability ID may be a subsidiary node value of the first IoT device on the Merkle tree.

6 is a flowchart illustrating an aspect in which a DTLS-based end-to-end security method is performed in an SP according to an embodiment of the present invention.

Referring to FIG. 6, in the above-described IoT environment, the method of operating the SP may include receiving a certificate issuance request for the first IoT device from the client and transmitting a certificate and a signature issued to the first IoT device. (S610); Receiving a request for issuance of a capability ID indicating the access right to IoT devices belonging to the first group to the SP, and transmitting the issued capability ID (S620).

The certificate is an elliptic curve Qu-Vanstone (ECQV) based certificate, and the signature may be generated based on a value of a second pre-image resistant hash function of the certificate.

The capability ID is a root hash node defined on a Merkle tree in which each of IoT devices belonging to the first group is located in a leaf node, a public key of the client, and the SP and the first agent. 1 may be generated using a public key shared in advance between IoT devices, and may be verified by a subsidiary node value of the first IoT device on the Merkle tree.

Security of the security method according to the invention

를 통해서 생성되기 때문에

의 안전한 유지관리는 필수적이다. In the DTLS-based end-to-end security method according to the present invention, since IoT devices belong to only one group of different subgroups. Clients can access IoT devices belonging to only one subgroup according to a defined capability list. In particular, when the client's capability ID is issued from the SP,

Because it is generated through

Safe maintenance is essential.

와 동일한 캐퍼빌리티 리스트에 접근이 가능한

를 생성하기 위해서는

를 통해서 생성이 되어야 한다.

이고

일 때, 공격자는

를 만족하는 ECDH 개인키/공개키

쌍을 찾아내야 하는데,

는

를 만족하는

를 찾을 수 없는 제2역상 저항성을 가지는 함수이기 때문에 불가능하다. 결국 캐퍼빌리티 ID를 위조하는 것 역시 불가능하게 된다.The safety of the DTLS handshake proposed in the present invention is based on the fact that the capability ID cannot be forged. The adversary

Access to the same capabilities list

In order to generate

It should be created via

ego

When is the attacker

ECDH private key / public key satisfying

I need to find a pair,

Is

To satisfy

This is impossible because it is a function with a second reverse phase resistance that cannot be found. In the end, forging a capability ID is also impossible.

)가 설정된다고 가정하였다. 이 가정의 현실성은 다음과 같이 설명 가능하다. 각 IoT 디바이스들은 LoWPAN에 배치되면서 IPv6 주소 설정을 위해서 6LBR과 6LoWPAN ND(Neighbor Discovery) 프로토콜 그리고 IEEE 802.15.4의 Pan Coordinator와 Join 프로토콜을 수행하게 된다. IoT 디바이스가 LoWPAN에 안전하게 배치되도록 하기 위해서는 결국 센서 디바이스와 PC 또는 6LBR 사이에 초기 보안설정을 위한 보안 부트스트래핑(security booststrapping) 과정이 필요한데 이 과정을 통해서 센서 디바이스와 SP간의 대칭키 설정이 가능하게 된다.Also, in the proposed protocol, the symmetric key (

) Is assumed. The reality of this assumption can be explained as follows. Each IoT device is deployed in LoWPAN and performs 6LBR, 6LoWPAN neighbor discovery (ND) protocol, and Pan Coordinator and Join protocol of IEEE 802.15.4 for IPv6 address setting. In order to securely deploy IoT devices in LoWPAN, a security booststrapping process is required for initial security configuration between the sensor device and the PC or 6LBR. This process enables the symmetric key configuration between the sensor device and the SP. .

Performance evaluation of security method according to the present invention

The experimental environment used Contiki 3.0 and the IoT device is a TI CC2538em that supports the ARM Cortex-M3 Processor (32 MHz), 512KB Flash, 32KB RAM and 4KM ROM. The 6LBR was configured by porting CETIC 6lbr to Raspberry Pie 2 and porting TinyDTLS to CC2538em and Ubuntu PC. The cc2538em provides a Pseudo Random Number Generator (PRNG) that uses a 16-bit Linear Feedback Shift Register (LFSR) to generate random numbers. The elliptic curve parameter is set to secp256r1, the cipher hash function is SHA-256, the message integrity code is AES-CBC-MAC-128, and the key derivation function is HMAC-SHA-256.

,

,

,

및

실행에 사용된 메시지 길이는 32바이트, 키 길이는 16바이트를 기준으로 하였다. ECQV는 단일 스칼라 곱셈을 이용한 실행시간, ECDSAc는 ECDSA 생성시간, ECDSAt는 ECDSA 검증시간 그리고 EnC는 대칭키 암호화 계산시간이다.Table 2 below shows the average execution time of cryptographic primitives used in the DTLS handshake in various security modes.

,

,

,

And

The message length used for execution was based on 32 bytes and the key length was 16 bytes. ECQV is the execution time using single scalar multiplication, ECDSAc is the ECDSA creation time, ECDSAt is the ECDSA verification time, and EnC is the symmetric key encryption calculation time.

Primitive Parameter Execution Time

secp256r1 1100.83 ms

secp256r1 1150.97 ms

secp256r1 1249.09 ms

AES-CTR-128 0.38ms

SHA-256 0.39 ms

AES-CBC-MAC-128 0.76 ms

HMAC-SHA-256 6.10 ms

16-bit LFSR
with radio ADC 0.06 ms

7 is a graph showing the results of measuring DTLS handshake delay time in PSK, RPK, certificate (ECDSA-equipped X.509 certificate and ECQV certificate) mode together with the proposed protocol.

In each step (①②③) in FIG. 3, the execution time of receiving and processing a packet from the client and transmitting the packet to the client was measured at the server side (each step means security negotiation, key exchange, and key verification). Proposed 1 and 2 represent the initial and subsequent DTLS handshake, respectively. PSK, ECQV, Proposed 1 and Proposed 2 do not show much difference in ① and ②. For RPK and X.509, the execution time in step ② is measured as 2,282 ms and 2.366 ms due to ECDSA signature generation, and in step ③ it is measured as 3.391 ms and 3.987 ms, respectively. In the ECQV certificate method, two EC scalar multiplications are performed by the server and the client, respectively, but the proposed protocol reduces the time required by performing only one time on the server. This reduces the burden on resource-constrained sensor devices, making Proposed 1 more efficient than ECQV authentication. As for (3), Proposed 2 shows execution time comparable to PSK.

8 is a graph illustrating a result of measuring DTLS handshake round trip delay for each security mode on a 6LoWPAN network.

Referring to FIG. 8, it can be seen that Proposed 1 has a significantly shorter round-trip delay time compared to RPK and X.509 certificate security modes, and Proposer 2 has a round trip delay time corresponding to the PSK security mode. On the other hand, for X.509 and ECQV, there is no delay in certificate validation with the CA.

The methods according to the invention can be implemented in the form of program instructions that can be executed by various computer means and recorded on a computer readable medium. Computer-readable media may include, alone or in combination with the program instructions, data files, data structures, and the like. The program instructions recorded on the computer readable medium may be those specially designed and constructed for the present invention, or may be known and available to those skilled in computer software.

Examples of computer readable media may include hardware devices specifically configured to store and execute program instructions, such as ROM, RAM, flash memory, and the like. Examples of program instructions may include high-level language code that can be executed by a computer using an interpreter, as well as machine code such as produced by a compiler. The hardware device described above may be configured to operate with at least one software module to perform the operations of the present invention, and vice versa. In addition, the above-described method or apparatus may be implemented by combining all or part of the configuration or function, or may be implemented separately.

Although described above with reference to a preferred embodiment of the present invention, those skilled in the art will be variously modified and changed within the scope of the invention without departing from the spirit and scope of the invention described in the claims below I can understand that you can.

Claims (18)

Internet of Things (IoT) devices belonging to a first group of at least one group, a client having access to IoT devices belonging to the first group, and a security proxy (SP) existing between the IoT devices and the client a security operation method of a first IoT device Sx among the IoT devices in an IoT environment including a security proxy,
Requesting the SP to issue a certificate for itself;
Receiving a certificate and a signature from the SP and deriving its own private and public key using the certificate and signature and the public key of the SP; And
Performing an initial DTLS handshake with the client in a certificate mode based on the certificate and the public key of the client,
In the initial DTLS handshake process, a PSK token of the client to be used in a subsequent DTLS handshake performed in a pre-shared key (PSK) mode between another IoT device belonging to the first group and the client is provided to the client.
How security works for IoT devices. The method according to claim 1,
The certificate is an ECQV (elliptic curve Qu-Vanstone) based certificate,
How security works for IoT devices. The method according to claim 2,
The signature is generated based on a value of a second pre-image resistant hash function of the certificate,
How security works for IoT devices. The method according to claim 1,
The initial DTLS handshake is
Receiving a random number N _A from the client;
Delivering the certificate and a random number (N _x ) to the client;
An authentication key derived from the client using the public key Q _A of the client, the capability ID of the client, a value for verifying the capability ID, and the certificate and the public key of the SP And receiving an integrity verification code of the session key;
Computing an authentication key and a session key, confirming the calculated integrity of the authentication key and the session key using the integrity verification code, and verifying the capability ID using a value for verifying the capability ID. Checking access rights for the first group of clients; And
If the integrity and the access right are verified, passing the client's pre-shared key (PSK) token to be used in a subsequent DTLS handshake between another IoT device belonging to the first group and the client; doing,
How security works for IoT devices. The method according to claim 4,
The capability ID is a root hash node defined on a Merkle tree in which each of IoT devices belonging to the first group is located in a leaf node, a public key of the client, and the SP and the first agent. 1 generated using a public key shared in advance between IoT devices,
How security works for IoT devices. The method according to claim 5,
The value for verifying the capability ID is a subsidiary node value of the first IoT device on the Merkle tree,
How security works for IoT devices. Internet of Things (IoT) devices belonging to a first group of at least one group, a client having access to IoT devices belonging to the first group, and a security proxy (SP) existing between the IoT devices and the client In the IoT environment including a security proxy, as the operating method of the client,
Requesting the SP to issue a capability ID indicating access authority to IoT devices belonging to the first group and receiving the capability ID; And
Performing an initial DTLS handshake in a certificate mode based on a certificate of the first IoT device and the first IoT device and the public key of the client, among the IoT devices belonging to the first group;
In the initial DTLS handshake process, the PSK token of the client to be used in a subsequent DTLS handshake performed in a pre-shared key (PSK) mode between another IoT device belonging to the first group and the client is provided from the first IoT device. felled,
How the client works securely. The method according to claim 7,
The certificate of the first IoT device is an ECQV (elliptic curve Qu-Vanstone) based certificate,
How the client works securely. The method according to claim 7,
The signature is generated based on the value of the second pre-image resistant hash function of the certificate,
How the client works securely. The method according to claim 7,
The initial DTLS handshake is
Delivering a random number N _A to the first IoT device;
Receiving the certificate and random number N _x from the first IoT device;
_A public key (Q _A ) of the client, a capability ID of the client, a value for verifying the capability ID, and an authentication key and a session key derived using the certificate and the public key of the SP delivering an integrity verification code of a session key to the first IoT device; And
When the integrity of the authentication key and the session key and the access authority indicated by the capability ID are confirmed, the PSK (pre-shared) of the client to be used in a subsequent DTLS handshake between another IoT device belonging to the first group and the client key) receiving a key from the first IoT device,
How the client works securely. The method according to claim 10,
The integrity of the authentication key and the session key confirms the integrity of the authentication key and the session key calculated by the first IoT device using the integrity verification code, and the access right uses a value for verifying the capability ID. Performing the verification by verifying the capability ID
How the client works securely. The method according to claim 7,
The capability ID is a root hash node value defined on a Merkle tree where each of IoT devices belonging to the first group is located in a leaf node, a public key of the client, and the SP and the SP. Generated using a public key shared in advance between the first IoT devices,
How the client works securely. The method according to claim 12,
The value for verifying the capability ID is a subsidiary node value of the first IoT device on the Merkle tree,
How the client works securely. Internet of Things (IoT) devices belonging to a first group of at least one group, a client having access to IoT devices belonging to the first group, and a security proxy (SP) existing between the IoT devices and the client In the IoT environment including a security proxy, the operation method of the SP,
Receiving a certificate issuance request for a first IoT device from the client, and transmitting a certificate and a signature issued to the first IoT device; And
Receiving a request for issuing a capability ID indicating the access right to IoT devices belonging to the first group to the SP and delivering the issued capability ID;
The capability ID is a root hash node defined on a Merkle tree in which each of IoT devices belonging to the first group is located in a leaf node, a public key of the client, and the SP and the first agent. 1 generated using a public key shared in advance between IoT devices,
How secure proxy works. The method according to claim 14,
The certificate is an ECQV (elliptic curve Qu-Vanstone) based certificate,
How secure proxy works. The method according to claim 15,
The signature is generated based on a value of a second pre-image resistant hash function of the certificate,
How secure proxy works. delete The method according to claim 14,
The capability ID is verified by a subsidiary node value of the first IoT device on the Merkle tree,
How secure proxy works.

Images