KR101704540B1 - A method of managing group keys for sharing data between multiple devices in M2M environment - Google Patents

Abstract

The present invention relates to a method for managing a group key for sharing multiple device data of a M2M system. The method for managing the group key for sharing multiple device data of the M2M system comprises: a step for requesting a service for exchanging a public key; a step of registering an initial user; a step of adding a device for establishing a security session between an M2M master device and an M2M slave device; and a step of sharing data between the M2M master device and the M2M slave device. The present invention can be used in a device in an M2M environment with reference to a CoAP message format and a data flow.

Description

[0001] The present invention relates to a group key management method for managing a plurality of groups of keys,

The present invention relates to a group key management method for data sharing between devices by generating and storing an encryption key in an M2M environment.

Machine-to-machine (M2M) environments, which refer to the communication between machines, have been increasing in recent years with the emergence of convergence services, and the overall requirements of the use of numerous devices have increased. We are in the process of standardization of security technology for each area.

Currently, M2M security technology trends are focused on analysis of key security requirements of M2M environment. The main subject of M2M related security technology at home and abroad is the use of M2M service using user devices. It is difficult to say that M2M concept is a complete M2M concept.

As of the first half of 2015, M2M standards are in the process of protocol standardization for data exchange. Therefore, most of the studies before 2015 are proposed as a protocol different from the actual standard protocols of M2M.

The existing research has the problem that the encryption algorithm (RSA, PKI infrastructure, etc.), which is difficult to apply to real devices, is applied because it does not consider the application of lightweight cryptography to the M2M environment, resulting in a large overhead.

In order to solve the above-mentioned problems, the present invention provides a group key management method for mutual authentication among a plurality of M2M devices, performing secure data sharing among devices having different service areas based on mutual authentication between an M2M device and a server The purpose of that is to do.

The objects of the present invention are not limited to the above-mentioned objects, and other objects not mentioned can be clearly understood by those skilled in the art from the following description.

According to another aspect of the present invention, there is provided a group key management method for sharing multiple device data in an M2M system, the method comprising: receiving one or more M2M servers connected to the M2M gateway and one or more M2M gateways connected to the M2M server; A method of managing a group key for sharing a multi-device data in an M2M system, the method comprising: a service request step of the M2M master device and the M2M server generating respective private keys and public keys and exchanging the generated public keys; An initial user registration step of exchanging an encrypted message with a signature generated by the M2M master device and the M2M server; The M2M master device exchanges a public key and a signature with the M2M slave device in response to a request for adding a new M2M slave device of the M2M master device to establish a security session between the M2M master device and the M2M slave device An additional step; Wherein the M2M master device generates a session key when the M2M master device makes a data sharing request and the M2M slave device makes a data sharing acknowledgment response, the M2M server generates a session key, and the M2M server authenticates the M2M master device and the M2M slave device, And the M2M server relays data between the M2M master device and the M2M slave device and shares the data; And releasing the M2M device in response to the device release request of the M2M device; Wherein the private key is randomly extracted from a set of natural numbers less than q, and the public key is generated from the private key using an elliptic curve cryptography method, (Elliptic Curve Digital Signature Algorithm (EGS)), which encrypts and decrypts data by using an ElGamal Encryption method based on an elliptic curve cryptosystem and applies the hash function by combining a message and a time stamp. ), And confirms whether the message encrypted by using the created signature is created by the signer.

According to the present invention, a CoAP message format and a data flow, which are currently adopted as a protocol for providing reliability, can be considered and implemented in a device in an actual M2M environment.

In addition, mutual authentication and signature generation, message and signature verification can be efficiently performed by applying ECC (Elliptic curve cryptography), which is mutually authentic and feasible with efficiency, for applying lightweight encryption, Elliptic Curve Diffie-Hellman (ECDH) for key exchange, Elliptic Curve Digital Signature Algorithm (ECDSA) for signature generation, and the like.

1 shows an abstract layer of a CoAP;
2 is a diagram showing a message format of a CoAP;
3 is a diagram showing the reliability and unreliable message transmission of CoAP;
4 is a configuration diagram of an M2M environment according to the present invention;
5 is a block diagram illustrating a group key management method for multi-device data sharing in the M2M system according to the present invention.
6 is an exemplary diagram illustrating a message procedure flow in a service request step according to a partial embodiment of the present invention;
FIG. 7 is an exemplary diagram for explaining a message procedure flow in an initial user registration step according to a partial embodiment of the present invention; FIG.
8 is an exemplary diagram for explaining a message procedure flow in a device adding step for data sharing according to a partial embodiment of the present invention;
FIG. 9 is an exemplary diagram for explaining a flow of a message procedure in a step of sharing data between devices according to a specific embodiment of the present invention; FIG.
10 is an exemplary diagram for explaining a message procedure flow in a step of releasing a service and a device according to a partial embodiment of the present invention;

BRIEF DESCRIPTION OF THE DRAWINGS The advantages and features of the present invention, and the manner of achieving them, will be apparent from and elucidated with reference to the embodiments described hereinafter in conjunction with the accompanying drawings. The present invention may, however, be embodied in many different forms and should not be construed as being limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art. Is provided to fully convey the scope of the invention to those skilled in the art, and the invention is only defined by the scope of the claims. It is to be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. In the present specification, the singular form includes plural forms unless otherwise specified in the specification. As used herein, the terms " comprises, " and / or "comprising" refer to the presence or absence of one or more other components, steps, operations, and / Or additions.

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

Table 1 shows requirements according to security functions according to the present invention.

division Security Features Security requirements
Authentication key management function
Before sending and receiving information data to and from the NSCL (Network Service Capability Layer) of the M2M server platform, authentication keys for service connection are created and stored

Cryptographic security of the generated authentication key

Secure storage of cryptographic keys

Authentication, Authorization
Authenticate via application authentication key before initiating message transfer with M2M endpoint application

Mutual authentication between device and server

Encryption of communication contents

Set access rights before accessing resource data in service function layer

Set correct access rights per service user

Data Integrity Check
Checks the integrity of data when transferring data between M2M terminal application and DSCL (Device Service Capability Layer)

Data integrity check between Device and DSCL

Checks the integrity of data when transferring data between service functions.

Data integrity check between same or different services

Checks the integrity of data between M2M terminal and M2M server platform

End-to-end data integrity check

ETSI TS 102 689 is a standard that defines the requirements for M2M services. It includes general requirements for M2M services, management, functional requirements for M2M services, Security, naming and addressing (Naming, Numbering and addressing).

The security management (DESC) function of the M2M device derives authentication keys for M2M service activation and connection through successful mutual authentication between the M2M terminal and the M2M service provider and protects the authentication keys from unauthorized access from outside the security environment .

In order to authenticate the M2M terminal application, an authentication key for application authentication is generated using the authentication keys generated in the service activation and connection process, and the authentication keys are managed in the service function layer of the terminal.

And performs registration of the service function layer through mutual authentication between the M2M device 100 and the M2M service provider.

Rather than defining a particular service or authentication technology in the current M2M standard, it is a situation that selectively applies an authentication technology that meets requirements based on usage environments. The M2M environment basically requires mutual authentication technology for communication with different environments and other devices such as peripheral control services, different platforms, different communication technologies. In addition, encryption technology for sensitive information and non-repudiation technology for checking integrity are required.

Common security requirements include device-to-device authentication, rights management, data encryption, and integrity checking. Currently, the standard requires a compatibility protocol of authentication technology and a lightweight protocol for a limited environment in common in the environment. When the service is expected to be expanded in the future, the authentication key And a key management technique standard for authorization is required.

1 is a diagram showing an abstract layer of CoAP.

IETF, an Internet standards organization, has been conducting standard activities such as IPv6 and 6 LowPAN in anticipation that various devices will be connected to the Internet. Each working group is developing standards for low power and small devices.

Currently, UDP-based CoAP standardization and trials are completed (November, 2013). In addition, standardization of CoAP use is underway in other transport layers (SMS, TCP, etc.). The CoAP protocol is based on the IEEE 802.15.4 standard for low-power sensor nodes, and the 6LoWPAN protocol is located in the layer for the interface between the network layer IPv6 protocol and the IEEE 802.15.4 standard. The target of the CoAP is a constrained node which has a low performance CPU, a small amount of RAM, and a ROM. The main goal is to provide a lightweight application layer between different types of M2M devices (100) based on the REST architecture .

2 is a diagram showing a message format of the CoAP.

It operates on HTTP to enhance compatibility and provides a cache function inside the proxy to perform protocol conversion between non-constrained nodes in the HTTP area and constrained nodes in the CoAP area .

3 is a diagram showing the reliability and unreliable message transmission of the CoAP.

For the communication process, the CoAP defines four message types: confirmation type, unconfirmed type, acknowledgment, and reset. Basically, it is transmitted through interactions of request and response. By performing reliable message transmission and non-acknowledged message transmission using each message ID, a proxy operation, a service and resource search method necessary for the operation, a multicast, HTTP connection and so on.

The response according to the CoAP request is paired with each other through a field called a token, and a response to the delayed delay to the M2M device 100 entering the sleep mode using the held token can be processed. It supports Http based Get and Post request method, so it is easy to access resources of server, and it can perform data sharing function between sensors by including link information of several sensors in link format standard.

4 shows a configuration diagram of an M2M environment according to the present invention.

M2M Device, M2M Gateway, and M2M Server defined in the standard. The following are the assumptions required for service components.

1. Service It is possible to provide smart convergence service integrated with users by mutually applying 1: 1 or 1: N configuration.

2. The M2M Device must perform user registration more than once in order to transmit the unique parameters for key exchange necessary for mutual authentication.

3. The M2M platform integrated in the standard allows single or multiple devices to work together in different services.

4. The M2M gateway 300 has a storage space for storing and maintaining sessions and identifiers to be maintained in protocol execution.

5. The server provides the user-defined profile and key management functions defined in the M2M platform standard and assumes that it is a trusted server.

6. The server stores a minimum amount of identification information for all M2M devices communicating with the M2M platform. This is done in the user registration step.

7. All communication processes automatically perform all processes such as key renewal and key revocation after user registration (key generation step).

In the present invention, any one of the M2M devices 100 shown in FIG. 4 becomes the M2M master device 110 and establishes a security session for data sharing with the remaining M2M devices 100 to share data between the M2M devices 100 .

M2M Server, M2M Gateway and M2M device communicate using CoAP protocol.

Table 2 shows the parameter specifications of the encryption algorithm according to the present invention.

No. Parameters Description One DevicePu_Key Device public key 2 ServerPu_Key Server public key 3 DevicePr_Key Device private key 4 ServerPr_Key Server private key 5 Message ID Identification message 6 M PlainText 7 K_G Key Group 8 r Ephemeral Random Number 9 s Random Number (Session Key) 10 D_S _1, D_S ₂ Device digital signature 11 S_S _1, S_S ₂ Server digital signature 12 Ts Timestamp 13 D_C Device ciphertext 14 S_C Server ciphertext

Use the generic Alice and Bob when describing the encryption method in the name of both parties.

The key exchange algorithm used in the service registration process uses the Diffie-Hellman public key exchange method. The Diffie-Hellman public key exchange method is a method in which both parties Alice and Bob who exchange information exchange their private keys, generate public keys from their respective private keys, and exchange public keys. That is, Alice and Bob have the other party's public key. Alice and Bob create a new key using the exchanged public key and their private key, which is called a shared secret key. The shared secret key that Alice and Bob have has the same value and uses it to encrypt and decrypt.

To use the Diffie-Hellman public key exchange method it is easy to generate the public key from the private key, but it is difficult to calculate the private key from the public key. Also, it is difficult to calculate the shared secret key from the public key unless the private key is known, and Alice and Bob's public key should be difficult to generate the shared secret key.

If this condition is satisfied, the private key and the shared secret key are not exchanged in the encryption and decryption protocol, so that the security is maintained even if the public key to be exchanged is leaked.

The encryption algorithm used in the present invention uses an ECC-based ElGamal public key encryption method considering the performance of communication between multiple devices.

The elliptic curve based on finite field (Galois Field) GF (2p) is suitable for implementation in a special purpose computing device such as a VLSI chip in a mobile communication device based environment.

The ECC-based ElGamal public key encryption method is a cryptographic communication method between the two (for example, Alice and Bob). After Alice and Bob exchanged public keys, Bob transmits a public key using Alice's public key and his / To Alice, and Alice is an encryption method that decrypts the encrypted message using her private key and Bob's public key. Since the public key generated from the private key k is a circular group, a natural number less than the order of the group is randomly extracted and used as a private key, and then, by a prime order, The public key K is calculated using the infinite origin E ₁ (a ₁ , b ₁ ) on the elliptic curve to be determined. Here, K = k x E ₁ (a ₁ , b ₁ ) and x is an elliptic curve point scalar product. That is, a public key is generated from a private key using an elliptic curve (ECC), and a secret shared key is generated using a cyclic group (ElGamal).

DevicePr_Key denotes a private key of the M2M device 100, and DevicePu_Key denotes a public key of the M2M device 100. [ ServerPr_Key denotes a private key of the M2M server 200, and ServerPu_Key denotes a public key of the M2M server 200. [

The private key can be obtained from a random variable using order q. That is, DevicePr_Key means one integer included in the interval [1, q-1]. The public key can be computed from the modulus q, the elliptic curve p, and the private key. The elliptic curve p has the infinite origin E ₁ (a ₁ , b ₁ ). From the elliptic curve scalar point product (x), the public key E ₂ (a 2, b ₂ ) can be obtained using the following equation (1).

The infinite origin E ₁ (a ₁ , b ₁ ) of a given elliptic curve p is unique, and the infinite origin serves as an identity point for a cyclic group consisting of points on an elliptic curve.

The elliptic curve p, the constant q, the infinite origin E ₁ (a ₁ , b ₁ ) according to the present invention will be a predetermined value, and the public key calculated from the elliptic curve scalar point product (x) It becomes a point on the top. The nature of the cyclic group is that the value obtained by multiplying an arbitrary natural number by the elliptic curve scalar point with the public key is also a point on the elliptic curve.

It is not impossible to calculate the private key from the public key, but it is a method that is derived from the fact that finding the discrete log on the elliptic curve takes a long time (Intractability). The elliptic curve cryptosystem requires complex knowledge of the background and requires expertise in the technical field to implement it, and has a relatively less known aspect than the RSA encryption method. However, it has the advantage of providing a similar level of security while using shorter keys than RSA.

Table 3 is a table summarizing the above-described methods of generating a private key, a public key, a signature, and a cipher text.

No. Parameters Description One DevicePr_Key 163bit Interger Number 2 DevicePu_Key E ₁ (a ₁ , b ₁ )
E ₂ (a ₂ , b ₂ ) = DevicePr_Key x E ₁ (a ₁ , b ₁ ) 3 ServerPr_Key 163bit Integer Number 4 ServerPu_Key E ₁ (a ₁ , b ₁ )
E ₃ (a ₃ , b ₃ ) = ServerPr_Key x E ₁ (a ₁ , b ₁ ) 5 D_S ₁ , D_S ₂ D_S ₁ = r x (E ₁ (a ₁ , b ₁ ))
D_S ₂ = (h (M _d? Ts) + DevicePr_Key x D_S ₁ ) r ^-1 mod q 6 S_S ₁ , S_S ₂ S_S ₁ = s x (E ₁ (a ₁ , b ₁ ))
S_S ₂ = (h (M _s | Ts) + ServerPr_Key x S_S ₁ ) s ^-1 mod q 7 r Ephemeral Random Number 8 s The session key (Random Number) 9
D_C encryption D_C = (M _d | Ts) + r x E ₃ (a ₃ , b ₃ )
D_C = (M _d ) + DevicePr_Key x E ₃ (a ₃ , b ₃ ) Decryption M _d? Ts = D_C - (ServerPr_Key x D_S ₁ )
M _d = D_C - (ServerPr_Key x E ₂ (a ₂ , b ₂ )) 10
S_C encryption S_C = (M _s | Ts) + s x E ₂ (a ₂ , b ₂ )
S_C = (M _s ) + ServerPr_Key x E ₂ (a ₂ , b ₂ ) Decryption M _s | Ts = S_C - (DevicePr_Key x S_S ₁ )
M _s = S_C - (DevicePr_Key x E ₃ (a ₃ , b ₃ ))

Each private key (DevicePr_Key, ServerPr_Key) and the public key generated in (DeivcePu_Key, ServerPu_Key) is using a digital signature scheme of using the elliptic curve cryptography (ECC) algorithm in ElGamal-based and elliptic curve-based (ECDSA) signature (D_S ₁ , D_S ₂ , S_S ₁ , S_S ₂ ). The hash function h (M | Ts) may be any of SHA-1 160 bits, SHA-2, SHA-3, DES, 3DES, MD5sum, and RC4. The input value of the hash function may be a combination of a message M and a time stamp Ts. That is, the signatures (D_S ₂ , S_S ₂ ) may include a time stamp (Ts) for preventing a replay attack after a third party intercepts and stores the message before the synchronization process.

Modulo p Defines the elliptic curve obtained by the addition operation as p. The parameters that are declared as public key of M2M device are elliptic curve p, modulo q, E ₁ (a ₁ , b ₁ ), E ₂ (a ₂ , b ₂ ). While the parameters that are declared public key of the M2M server is q, E ₁ to the elliptic curve p, the module _{(a1, b1), E 3} (a 3, b 3).

The elliptic curve p, the modulo q and the infinite origin E ₁ (a ₁ , b ₁ ) are known values in the M2M environment according to the present invention, and the actually exchanged public keys are E ₂ (a ₂ , b ₂ ) and E ₃ a ₃ , b ₃ ).

Elliptic Curve-based Digital Signature Architecture (ECDSA) is a cryptographic technique that confirms that messages exchanged in encrypted communication are messages sent by the other party. When Alice sends a message m to Bob, Alice sends an additional signature (S ₁ , S ₂ ) to Bob. S ₁ and S ₂ satisfy the following equation (2).

Here, r denotes an ephemeral random number included in the interval [1, q-1], and S ₁ can play a role similar to a public key. X means an elliptic curve point multiplication by a scalar as in the above.

In the present invention, a hash function is applied by combining a time stamp with a message m. The signature used in the present invention is shown in Equation (2).

The signature is a means of verifying that the message received is correct. If the hash value of the decrypted message matches the hash value sent by the other party, it is confirmed that the decryption is successful. ECDSA uses the following method to check whether the hash values match.

And calculates w, u, v using the calculated signatures S ₁ , S ₂ .

How to calculate w, u, v is as follows.

In this case, hash (m || Ts), which is used to calculate u, combines the received message with the time stamp and applies the hash function to prevent the reuse attack. In order to make sure it matches the hash (m || Ts) used for S ₂ using the calculated w, u, v, and equation (5) to calculate the points (x _1, y ₁₎ on the elliptic curve.

When Equation (6) is satisfied, it is regarded that (m of S ₂ ) and (m of u) are coincident (possibility of non-coincidence is close to 0). That is, when Equation (6) is established, it is determined that the signature is correct.

S ₂ is encrypted is transmitted, but the protection primarily, be referred to if not encrypted for the efficiency, Hash (m), even if exposed by the attack hash function is a one-way function (irreversibility) m with Hash (m) Is stochastically scarce. Since the hash function corresponds to n: 1, even if m ≠ m ', Hash (m) = Hash (m') can be established with extremely low probability, but it can be disregarded.

According to the above-mentioned signature verification procedure (ECDSA), Bob can confirm that the given message is sent by Alice using the message m and signature (S ₁ , S ₂ ) received from Alice. In the present invention, it referred to as the signature of the Device D_S _{1, 2} D_S la, the Server's signature S_S _1, and S_S _2, as shown in Table 3.

In essence, it is important for ECDSA to randomly re-extract other r values for other signatures. Thus, often different signatures are used for each message, and a new r value is extracted.

In the present invention, the M2M server 100 creates a signature using s, which the M2M server 200 will use as a session key, and the M2M device 100 creates a signature using the value r. The session key used by the M2M server 200 can utilize the session key for more efficient data sharing when a security session is established, although both values are not different in that they are an ephemeral random number.

When data is shared by using session key, it can be vulnerable to reuse attacks. Therefore, it generates a hash function including a time stamp in a message to prevent a reuse attack.

FIG. 5 is a block diagram illustrating a group key management method for sharing multi-device data in the M2M system according to the present invention.

The communication step of the protocol of the group key management method for M2M system's multi-device data sharing includes (1) service request (S510), (2) user registration (S520), (3) add device (S530) S550). The respective steps will be described in detail in Figs. 6 to 10. Fig.

FIG. 6 illustrates an exemplary diagram for explaining a message procedure flow in a service request step (S510) according to a partial embodiment of the present invention.

The request message before user registration carries out identification by transmitting an identification message (message ID) of the CoAP. In order to generate and exchange necessary keys during the user registration process, the request message exchanged before the registration process simply uses the identifiable message. That is, in the service request step S510, the M2M master device 110 and the M2M server 200 exchange their generated public keys.

Since the service request step (S510) is before the public key exchange, all messages are transmitted in plaintext. The message exchange and data transmission at a later stage is transmitted as a ciphertext. The encryption key generating the ciphertext in the subsequent step may be encrypted using the public key, or may be encrypted using the signature generated including the session key. In addition, encryption and decryption may be performed using a public key, a session key, a time stamp, and the like, which are exchanged after establishing a secure session, using a symmetric secret key for use with both parties.

For example, in the initial user registration step (S520) and the device addition step (S530), the message is encrypted and decrypted using its own private key and the other party's public key since the signature is exchanged. In the data sharing step S540 in which data can be transmitted, public key encryption, encryption using a signature, and symmetric key encryption are all possible, and double encryption is also applicable. However, considering the M2M environment, it may be efficient to encrypt or decrypt using a signature including a session key, or using a symmetric secret key exchanged by the ElGamal encryption method.

7 is an exemplary diagram illustrating a message procedure flow in an initial user registration step (S520) according to a partial embodiment of the present invention.

Because it is necessary to verify that the correct M2M device is communicating for initial user registration, perform the key exchange preliminary step for mutual authentication. The identification message transmitted from the device is mapped to the public key and stored in the gateway and the server, and then the encrypted message is transmitted to the server. The server stores the M2M device identification values and verifies the identification values for each key update in subsequent communication to verify that they are communicating with the correct device. The device registered in the user registration step (S520) is designated to the M2M master device (110).

The signature value is a value generated by a product of an arbitrary number and the coordinates (E ₁ (a ₁ , b ₁ )) selected on the elliptic curve (Elliptic curve point multiplication by a scalar) And a timestamp for preventing a re-transmission attack.

Each generated ciphertext is encrypted using a plaintext M, an arbitrary number r, s or a private key, a point E ₂ or E ₃ on an elliptic curve, and in the case of decryption, using its own private key and each transmitted signature Decrypts the decrypted private key or decrypts it using its own private key and each public key (E ₂ or E ₃ ) received.

The M2M server 200 receives the signature (D_S ₁ , D_S ₂ ) and the encrypted text (D_C) created using the exchanged public key for initial user registration with the M2M device 100 (CoAP request) Sends a key group (K_G) and an OK message from the M2M device 100 (CoAP) to the M2M device 100 (S_S ₁ , S_S ₂ ) and encrypted text S_C Request) to complete the initial user registration (key group setting).

At this time, all the sending and receiving messages can be encrypted and decrypted using the private key and the public key, and can be encrypted and decrypted using the private key and signature. However, since the data format of the signature (D_S ₁ , S_S ₁ ) is the same as that of the public key, the encryption and decryption methods are the same (see Table 3).

FIG. 8 is an exemplary diagram illustrating a message procedure flow in a device adding step (S530) for data sharing according to a partial embodiment of the present invention.

The user can use the M2M service by adding devices of different services. And performs a request for adding a new device through the trusted M2M server 200. The additional device (M2M slave device 120 in FIG. 8) exchanges public key exchange and ciphertext for secure mutual authentication in the same manner as the registration step. The device is added to the key group of the initially registered M2M master device 110 and the new session key generated from the server is updated to exchange the cipher text and proceed with communication.

When the M2M master device 110 makes an Add Device Request to the M2M slave device 120, the M2M server 200 that registered the M2M master device 110 adds the M2M slave device 120 The process proceeds. This process is similar to the process flow between the M2M server 200 and the M2M master device 110 in FIGS. 6 through 7, except that information such as the public key and signature of the M2M slave device 120 is transmitted to the M2M master device 110). ≪ / RTI >

Exchanges the public key between the M2M server 200 and the M2M slave device 120, exchanges the signature file and the encrypted text, receives the OK message, stores it in the key group of the M2M master device 110 of the M2M server 200 A secure session is established between the M2M master device 110 and the M2M slave device 120. [

Since the M2M slave device 120 has responded to the device addition request of the M2M master device 110 with the OK message, the key group information for the M2M master device 110 stored in the server in the data sharing step (S540) Can be used to share security data.

FIG. 9 is an exemplary diagram for explaining a message procedure flow in the inter-device data sharing step (S540) according to the embodiment of the present invention.

After establishing a secure session for an authenticated device, for data sharing, the server creates a new session key and exchanges the ciphertext with each device and the new session key. The generated session key is updated by updating the r value or the s value used in generating the existing signature.

When the M2M master device 110 wants to share data with the M2M slave device 120, the M2M server 200 makes a data sharing request to the M2M server 200 and the M2M server 200 transmits the data sharing request to the M2M slave device 120, (S_S ₁ , S_S ₂ ) and encrypted text (S_C) to the M2M master device 110 and the M2M slave device 120 by generating a new session key (s) The security data can be shared between the M2M master device 110 and the M2M slave device 120. [

The M2M device 100 can share messages and data using the ElGamal encryption method based on the ECC curve described above. However, it is necessary to repeatedly send information other than the cyphertext (signature, etc.) 200 have to exchange data, and a protocol for exchanging signatures between the M2M server 200 and the M2M device 100 is inefficient, and there is a disadvantage that a private key can be leaked when the session key is repeatedly used.

To solve this problem, in a data sharing step (S540), a session key is generated for a 1: 1 matching relationship or a 1: N matching relationship between devices using the signature information to be exchanged, a symmetric secret key is generated based on the generated session key, A method in which the master device 110 and the M2M slave device 120 directly share data can be used.

The time stamp information can be used to prevent the reuse attack of the symmetric secret key generated including the session key.

10 is an exemplary diagram for explaining a message procedure flow in releasing a service and a device according to a partial embodiment of the present invention (S550).

The step S550 of releasing the device means a case where the M2M master device 110 is released and the M2M devices 100 interlocked with each other are released or the specific M2M slave device 120 is released.

When the M2M master device 110 is released, all keys added to the key group set in the initial registration are revoked. In the case of the specific device, the existing security session is maintained and the device to be released is released from the K_G.

In general, when the service is used, the master device is used in a form of adding or releasing a specific device while maintaining the session without releasing the user. Therefore, updating of the key of the M2M master device 110 is terminated (turned off) (Handover), or the user's request (re-registration).

After the session is released, the same session key update is performed as in the sharing step, and the session data is shared through the session re-establishment and the key group renewal.

The results of analyzing the stability of the proposed protocol according to the item of M2M service security requirement in (1) authentication management function (2) authentication, authorization setting, and (3) data integrity check are as follows.

(1) Authentication management function

ⅹ100% 수준의 공격 성공률을, 2048bit의 키에 대하여

ⅹ100% 수준의 공격 성공률로 공격이 어렵다. We used an elliptic curve algorithm with a 163 bit key length that conforms to the RSA 1024 bit stability to enable legitimate device or mutual authentication through key exchange for data sharing of the M2M server (200) platform. The security of the elliptic curve-based signature private key used in the algorithm is based on the 1024-bit key, which is the same level as the RSA at the off-line level,

Ⅹ100% level of attack success rate, about 2048bit key

It is difficult to attack with 100% attack rate.

If the 163-bit key of the private key of the elliptic curve algorithm used in the protocol is increased, the complexity of the algorithm level can be increased in multiples. The M2M server 200 is able to perform key management such as generation, update, and revocation of keys without intervention of the user in the entire operation process with the same concept as CA, which is a trusted authority.

(2) authentication, authorization setting

The mutual authentication between the devices is performed before the data sharing of the device through the initial user registration step S520 and the generated authentication key is secure because all processes except the public key exchange with the first identifier M are encrypted and exchanged . Even if the attacker masquerades as a device or a server for the established security session, it can not infer the correct message and session key because it does not know the inverse value of the private key used in each generated ciphertext.

Also, in order to encrypt the communication contents of each other device, a new session key is generated in data sharing, and the access right between the devices can be confirmed by checking whether the same key group is requested by the user.

(3) Data Integrity Check

Use a hash function, including a message and a timestamp, in the generated signature for data integrity in data encryption. Timestamps prevent replay attacks. In addition to the device and server identifier and the public key, all messages are transmitted encrypted with the renewed session key, so it is safe to reuse attacks that reuse the messages collected in the previous session for the next session. The symmetric key algorithm that can be applied to SHA-1 other than the applied SHA-1 can be extended according to the characteristics of the environment such as DES, 3DES, and RC4.

Even if the user initially registers the device to be registered as a master and added to another service, the server encrypts and distributes it using the signature including the session key. In order to improve the efficiency of the operation generated in the signature, only the session key is updated and the algorithm is executed. When the signature is regenerated, it is performed only when the device is released, thereby reducing the overhead of the operation as much as possible.

While the present invention has been described in detail with reference to the accompanying drawings, it is to be understood that the invention is not limited to the above-described embodiments. Those skilled in the art will appreciate that various modifications, Of course, this is possible. Accordingly, the scope of protection of the present invention should not be limited to the above-described embodiments, but should be determined by the description of the following claims.

100: M2M device
110: M2M master device
120: M2M slave device
200: M2M server
300: M2M gateway
S510: Service request step
S520: Initial user registration step
S530: Device addition step
S540: Data sharing step
S550: Device release step

Claims (6)

A group key management method for multi-device data sharing in an M2M system including one M2M server, one or more M2M gateways connected to the M2M server, and one or more M2M devices connected to the M2M gateway,
A service request step of the M2M master device and the M2M server generating respective private keys and public keys and exchanging the generated public keys;
An initial user registration step of exchanging an encrypted message with a signature generated by the M2M master device and the M2M server;
The M2M master device exchanges a public key and a signature with the M2M slave device in response to a request for adding a new M2M slave device of the M2M master device to establish a security session between the M2M master device and the M2M slave device An additional step;
Wherein the M2M master device generates a session key when the M2M master device makes a data sharing request and the M2M slave device makes a data sharing acknowledgment response, the M2M server generates a session key, and the M2M server authenticates the M2M master device and the M2M slave device, And the M2M server relays data between the M2M master device and the M2M slave device and shares the data; And
Releasing the device in response to a request to release another M2M device of the M2M device,
Wherein the private key is randomly extracted from a set of natural numbers less than q,
The public key is generated from the private key using an elliptic curve cryptography method,
Encrypting and decrypting the data by an ElGamal method based on an elliptic curve cryptosystem using the private key and the public key,
The signature is generated by an elliptic curve digital signature algorithm that applies a hash function by combining a message and a time stamp,
And verifies whether the message encrypted by using the created signature has been created by the signer
A Group Key Management Method for Multi - Device Data Sharing in M2M System.
The method according to claim 1,
The hash function is any one of SHA1, DES, 3DES, RC4
A Group Key Management Method for Multi - Device Data Sharing in M2M System.
The method according to claim 1,
Wherein the network to which the M2M server, the M2M gateway and the M2M device are connected is a sensor network compliant with IEEE 802.15.4
A Group Key Management Method for Multi - Device Data Sharing in M2M System.
The method of claim 3,
The protocol for transmitting a message in the sensor network is CoAP (Constrained Application Protocol)
A Group Key Management Method for Multi - Device Data Sharing in M2M System.
The method according to claim 1,
In the initial user registration step, the signature is encrypted using the public key of the other party and its own private key, and the encrypted message is transmitted to the user through the encryption method using the signature of the other party and its own private key, By using the encryption method using the private key of < RTI ID = 0.0 >
A Group Key Management Method for Multi - Device Data Sharing in M2M System.
The method according to claim 1,
The step of sharing the data
The M2M server generates a session key s using a random generator and transmits a cipher text obtained by encrypting the session key s using its own private key and a public key of the other party to the M2M master device and the M2M slave device, And the key is used as a shared secret key to share the data.
A Group Key Management Method for Multi - Device Data Sharing in M2M System.

Images