SDP-based information protection method and device for IoT cloud security

Abstract

To provide an information protection method and a device that effectively block potential attacks by isolating access control and data communication through authentication and encryption without disclosing a protected object to the outside by extending a software-defined perimeter (SDP).SOLUTION: A method includes the steps of: receiving, by an SDP controller, an onboard request message via an ID token from an SDP client which is an initiating host; and issuing SDP client credentials suitable for handshake parameters, wherein the onboard request message includes: information requesting authentication of the SDP client; and the handshake parameters for specifying a handshake protocol in an SDP access process.SELECTED DRAWING: Figure 2

Description

[Technical field]

[0001] The present disclosure relates to a software-defined perimeter (SDP)-based information protection technology for Internet of Things (IoT) cloud security, and more particularly to an information protection method and device that extends the SDP to separate access control and data communication through authentication and encryption without exposing the protected object to the outside, thereby effectively blocking potential attacks. [Background technology]

[0002] A traditional software-defined perimeter (SDP) includes an onboarding process for adding a new single packet authorization (SPA) client to the SDP environment, and an access process for sending messages between objects. During the access process, a transport layer security (TLS) handshake is used to protect messages sent between objects with asymmetric key encryption.

[0003] Meanwhile, in the case of an SPA client, before a mutually trusted session is established, a single packet is sent to a closed port, and the port is opened outside the firewall, so brute force attacks and replay attacks can be prevented. At this time, the format of the SPA message may vary depending on the implementation method of SDP, but the creator and receiver of the packet must share a shared secret and a reliable security channel.

[0004] In addition, the lightweight handshake protocol, designed for setting up security sessions between devices in resource-constrained environments, ensures smaller message sizes than the TLS handshake, but the TLS handshake in SDP is still difficult to apply to low-performance or low-spec devices.

[0005] Thus, there is a need for a way to effectively apply security to small Internet of Things devices that represent the internet of small things, as well as to low performance computing power based devices used in the Internet of Things and the like.

[0006] In particular, with the expansion of the Internet of Things cloud market, there is an increasing demand for lightweight SDP solutions that can flexibly set security boundaries regardless of the location of the protected resources and prevent network-based attacks. Summary of the Invention [Problem to be solved by the invention]

[0007] The present disclosure has been made to overcome the problems of the above-mentioned conventional technology, and an object of the present disclosure is to provide an SDP-based information protection method and device for Internet of Things (IoT) cloud security that can support efficient resource usage of software-defined perimeter (SDP) solutions by using an EDHOC (Ephemeral Diffie-Hellman Over COSE) protocol, which is lighter than a TLS (transport layer security) handshake.

[0008] Another object of the present disclosure is to provide an SDP-based information protection method and device that can provide flexible authentication security in various environments through the extensibility of SDP environment configuration by combining TLS-based SDP and EDHOC-based SDP so as to maintain compatibility with existing technologies. [Means for solving the problem]

[0009] An SDP-based information protection method according to one aspect of the present disclosure for solving the above technical problems is a software-defined perimeter (SDP)-based information protection method for Internet of Things cloud security, and includes a step of receiving, by an SDP controller, an onboarding request message via an identity token from an SDP client which is an initiating host (the onboarding request message includes information requesting authentication of the SDP client and handshake parameters for specifying a handshake protocol in the SDP access process), and a step of issuing, by the SDP controller, SDP client credentials suitable for the handshake parameters.

[0010] The SDP-based information security method may further include a step of transmitting, by the SDP controller, the SDP client credentials to the SDP client, and a step of receiving, by the SDP controller, a receipt response of the SDP client credentials from the SDP client.

[0011] The handshake parameters include handshake parameter values ​​that specify a TLS handshake protocol, an EDHOC handshake protocol, and an extended EDHOC handshake protocol.

[0012] The SDP-based information protection method may further include using a TLS handshake as a default if the handshake parameters are not specified.

[0013] The SDP client credentials may include a handshake encryption key, a handshake certificate, an SPA encryption key, and an SPA hash-based message authentication code (HMAC) key.

[0014] The SDP-based information protection method may further include a step of including a Diffie-Hellman (DH) shared secret for generating a DH private key in the SDP client credential.

[0015] The SDP-based information protection method may further include the steps of receiving an SPA packet from the SDP client, setting up an open TCP connection between the SDP controller and the SDP client via the SPA packet, and receiving a first EDHOC message from the SDP client.

[0016] The steps of receiving the SPA packet and receiving the first EDHOC message may include receiving an SPA packet to which the first EDHOC message is associated.

[0017] The SPA packet to which the first EDHOC message is bound may include an IP header, a TCP header, and a TCP payload, where the TCP payload may include the SPA message and the EDHOC message.

[0018] The SDP-based information protection method may further include a step of encrypting data elements of the first EDHOC message that require security.

[0019] The SDP-based information protection method may further include a step of combining an SPA message of the SPA packet with the first EDHOC message, and a step of omitting data elements of the first EDHOC message that may overlap with data elements of the SPA message when generating the SPA packet through the combining step.

[0020] The SDP-based information protection method may further include the steps of verifying the SPA packet, setting up a TCP connection if the SPA packet is verified, processing an EDHOC handshake with the first EDHOC message if the TCP connection is set up, and setting up a security session between the SDP client and the SDP controller if the EDHOC handshake is processed.

[0021] The SDP-based information protection method may further include a step of receiving a login request message including the SDP client credentials from the SDP client after the security session is established, and a step of confirming that the SDP client is in an active state through the login request message.

[0022] The SDP-based information protection method may further include the steps of: transmitting an initiating host service message to the SDP client; and transmitting an initiating host authentication message to another SDP client that is an accepting host.

[0023] According to another aspect of the present disclosure for solving the above technical problem, an SDP-based information protection device for Internet of Things cloud security includes instructions stored in a memory or a storage device, and a processor mounted on an SDP controller for executing the instructions. The processor may receive an onboarding request message via an identity token from an SDP client that is an initiating host (the onboarding request message includes information requesting authentication of the SDP client and handshake parameters for specifying a handshake protocol in an SDP access process), and issue an SDP client credential suitable for the handshake parameters by the SDP controller.

[0024] The handshake parameters may include handshake parameter values ​​that specify a TLS handshake protocol, an EDHOC handshake protocol, and an extended EDHOC handshake protocol.

[0025] The SDP-based information protection device may further perform, by the processor, a step of including a Diffie-Hellman (DH) shared secret for generating a DH private key in the SDP client credential.

[0026] The SDP-based information protection device may further perform the steps of: receiving, by the processor, an SPA packet from the SDP client; setting, by the processor, an open TCP connection between the SDP controller and the SDP client via the SPA packet; and receiving, by the processor, a first EDHOC message from the SDP client.

[0027] The SDP-based information protection device may, by the processor, perform the step of receiving the SPA packet and the step of receiving the first EDHOC message, a step of receiving an SPA packet to which the first EDHOC message is combined.

[0028] The SPA packet to which the first EDHOC message is bound may include an IP header, a TCP header, and a TCP payload, where the TCP payload may include the SPA message and the EDHOC message.

[0029] The SDP-based information protection device may further perform, by the processor, a step of omitting data elements from the first EDHOC message that may overlap with data elements of the SPA message when generating the SPA packet. Effect of the Invention

[0030] According to the present disclosure, by using the Ephemeral Diffie-Hellman Over COSE (EDHOC) protocol, which is lighter than the transport layer security (TLS) protocol, it is possible to provide efficient security for Internet of Things (IoT) devices by making the software-defined perimeter (SDP) security configuration lighter, reducing network bandwidth, and reducing memory usage.

[0031] Also, according to the present disclosure, it is possible to provide scalability of a handshake protocol for configuring an SDP environment in Internet of Things cloud security. That is, it is possible to provide a workflow that allows the selection of another handshake protocol, the EDHOC protocol, while maintaining the existing SDP environment configuration function in Internet of Things cloud security, i.e., the TLS handshake. Also, it is possible to provide a workflow that allows the selection of another handshake protocol, the lightweight EDHOC protocol, while ensuring the security of the existing TLS level, for example, the TLS1.3 level. In this case, it is possible to provide scalability of the SDP environment configuration while maintaining compatibility with existing technologies, and to realize authentication security that flexibly operates in various IoT environments. [Brief description of the drawings]

[0032]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

[0033] Since the present invention can be modified in various ways and can have various embodiments, a specific embodiment is shown in the drawings and described in detail, but this does not limit the present invention to the specific embodiment, and it should be understood that the present invention includes all modifications, equivalents, and alternatives included in the spirit and technical scope of the present invention.

[0034] Terms such as first, second, etc. may be used to describe various components, but the components should not be limited by the terms. The terms are used only to distinguish one component from another. For example, a first component may be referred to as a second component, and similarly, a second component may be referred to as a first component, without departing from the scope of the invention. The term "and / or" includes a combination of multiple associated listed items or any of multiple associated listed items.

[0035] In the embodiments of the present application, "at least one of A and B" may mean "at least one or a combination of two or more that can be selected from A and B." Also, in the embodiments of the present application, "one or more of A and B" may mean "at least one or more including all combinations that can be selected from A and B."

[0036] When a component is described as being "coupled" or "connected" to another component, it should be understood that it may be directly coupled or connected to the other component, but there may also be other components between them. On the other hand, when a component is described as being "directly coupled" or "directly connected" to another component, it should be understood that there are no other components between them.

[0037] The terms used in this application are merely used to describe certain embodiments and are not intended to limit the present invention. A singular expression includes a plural expression unless the context clearly indicates otherwise. In this application, the terms "include" or "have" and the like specify the presence of features, numbers, steps, operations, components, parts, or combinations thereof described in the specification, and should be understood not to preclude the presence or addition of one or more other features, numbers, steps, operations, components, parts, or combinations thereof.

[0038] Unless otherwise defined, all terms used herein, including technical and scientific terms, have the same meaning as commonly understood by a person of ordinary skill in the art to which this invention pertains. Terms defined in commonly used dictionaries should be interpreted to have a meaning consistent with the contextual meaning of the relevant art, and should not be interpreted in an idealized or overly formal sense unless expressly defined in this application.

[0039] Hereinafter, a preferred embodiment of the present invention will be described in more detail with reference to the accompanying drawings. The following detailed description is provided for illustrative purposes only and should not be construed as limiting the concept of the present invention to any specific physical configuration. In describing the present invention, in order to facilitate overall understanding, the same components on the drawings will be given the same reference numerals, and duplicated descriptions of the same components will be omitted.

[0040] FIG. 1 is a schematic diagram of a software-defined perimeter (SDP) architecture in which an information security approach according to one embodiment of the present disclosure can be employed.

[0041] SDP is an information protection method that blocks potential attacks through authentication and encryption without exposing the protected object to the outside. SDP is used to protect the network with the aim of minimizing vulnerabilities and the risk of sensitive information being stolen by attackers. SDP blocks all requests to connect to the network based on the Zero Trust principle, verifies the identity of users when they access the network, and allows access to resources according to their privileges. Such SDP overcomes the limitations of existing centralized security methods in which IP ports are exposed to all users, and improves network performance by providing a direct connection between users and service providers.

[0042] 1, the SDP architecture may include a first SDP host 100, second SDP hosts 200, 210, and an SDP controller 300. The second SDP host 200 is one of a plurality of second SDP hosts, and may have the same configuration and functions as the plurality of second SDP hosts and may represent them.

[0043] The first SDP host 100 may be an initiating host (IH) that is an SDP client that initiates a process to access a protected resource via an accepting host (AH). The first SDP host 100 may be called the initiating SDP host.

[0044] The second SDP host 200 may be an accepting host (AH) that is an SDP client that basically blocks all network access, receives control information from the SDP controller 300, and is accessible only to an initiating host that receives an access instruction. The second SDP host 200 may be called an accepting SDP host.

[0045] The initiating host and the accepting host are SDP clients that process communication requests and authorizations, and the SDP controller 300 can manage authentication and access authority between the SDP clients. The initiating host and the accepting host are connected via a control plane, and the SDP controller and each SDP client can be connected via a data plane.

[0046] Each object of the SDP solution included in the SDP architecture can perform key exchange for mutual authentication and key exchange for communication security using a transport layer security (TLS) handshake.

[0047] FIG. 2 is a flowchart illustrating an onboarding process of an information security system according to an embodiment of the present disclosure.

[0048] The SDP onboarding process is the process by which a new single packet authorization (SPA) client is added to the SDP environment, and messages sent between objects can be protected by asymmetric key encryption. SPA clients may contain initiating and accepting hosts, just like SDP clients.

[0049] The onboarding process of SDP using TLS handshake will be described in more detail with reference to FIG. 2 as follows.

[0050] First, an ID provider (IdP) 400 can exchange information and data with an SDP client 100, which is an initiating host (IH). At this time, the SDP client 100 requests an ID token from the ID provider 400 (S21), and is issued an ID token from the ID provider 400 through user authentication (S22) (S23).

[0051] Then, the SDP client 100 may request SDP client authentication through the ID token to the SDP controller 300. That is, the SDP client 100 may transmit an onboard request message to the SDP controller 300 when transmitting the ID token. When transmitting the ID token, the SDP client 100 may transmit a handshake parameter specifying a type of handshake protocol for an access process to the SDP controller 300 (S24).

[0052] Examples of handshake parameters that specify the type of handshake protocol are shown in Table 1 below.

[0053] [Table 1]

[0054] If no handshake parameters are specified, the SDP controller 300 may be configured to use a TLS handshake as a default.

[0055] The SDP controller 300 can newly issue SDP client credentials suitable for the specified handshake protocol (S25) and transmit the newly issued credentials to the SDP client 100 (S26). That is, the SDP client 100 can receive the SDP client credentials from the SDP controller 300 (S26) and respond to the reception of the credentials to the SDP controller 300 (S27).

[0056] SDP client credentials may include a handshake encryption key, a handshake certificate, an SPA encryption key, and an SPA HMAC key. Hash-based message authentication code (HMAC) is a protocol used for cryptographic message authentication and a specialized hash string that allows an API server to verify the requester's identity and the integrity of the request message.

[0057] In addition, the SDP controller 300 can use ephemeral Diffie-Hellman over COSE (EDHOC) specified in the handshake parameters during the onboarding process of SDP using the TLS handshake. In particular, the SDP controller 300 can include a Diffie-Hellman (DH) shared secret for generating a DH private key in the credentials and transmit the credentials to the SDP client 100 (see S26).

[0058] Here, EDHOC is a very compact and lightweight authenticated Diffie-Hellman key exchange using ephemeral keys, which can provide mutual authentication, forward secrecy and identity protection in limited scenarios. EDHOC can keep the additional code size very small by reusing CBOR object signing and encryption (COSE) for encryption, concise binary object representation (CBOR) for encoding, and constrained application protocol (CoAP) for transport.

[0059] CBOR is a binary data serialization format based on JSON that can be used to more compactly transmit data objects that contain name-value pairs, similar to JSON, and may be the recommended data serialization layer for specialized Web Internet of Things protocol families such as CoAP and the data formats underlying COSE messages.

[0060] According to the present embodiment, a lightweight authentication security protocol and workflow can be configured in the SDP solution to replace the TLS handshake. That is, a workflow using the EDHOC protocol as a lightweight authentication security protocol to replace the TLS handshake can be provided.

[0061] FIG. 3 is a flowchart illustrating an access process of an information security method according to an embodiment of the present disclosure.

[0062] The access process of this embodiment is an SDP access process for using an optional handshake, and can be performed after the onboarding process described above with reference to FIG. 2. In particular, the access process of this embodiment uses an EDHOC handshake. That is, in the SDP environment configuration process, an EDHOC handshake is used instead of a TLS handshake. Assuming that the same algorithm is used, an EDHOC handshake has a smaller message size than a TLS handshake or a DTLS (datagram transmission layer security) handshake, and therefore, an efficient security session can be set up.

[0063] 3, the SDP client 100, which is an initiating host, can transmit an SPA packet to the SDP controller 300 (S31). The SDP controller 300 can receive the SPA packet from the SDP client 100 and verify the received SPA packet (S31a).

[0064] Once the SPA packet is verified, the SDP client 100 and the SDP controller 300 can open a TCP connection between each other (S32).

[0065] Then, as an EDHOC handshake process (S33), the SDP client 100 may transmit a first message (message_1) to the SDP controller 300 (S34). The first message may be an EDHOC message. The first message may be referred to as a first EDHOC message.

[0066] Then, if the SPA packet is verified, the SDP controller 300 processes the EDHOC handshake with the first message, sets up a security session between the SDP client 100 and the SDP controller, and then transmits a second message (message_2) related thereto to the SDP client 100 (S35). Also, the SDP controller 300 can receive a third message (message_3) from the SDP client 100 as a response to the second message (S36).

[0067] After the security session setup is complete, the SDP client 100, which is the initiating host, can send a login request message including credentials to the SDP controller 300 to inform the SDP controller 300 that it is active, and in response thereto, can receive a login response message from the SDP controller 300 (S37).

[0068] The SDP controller 300 then transmits an IH service message to the SDP client 100, which is the initiating host (IH) (S38), and can transmit an IH authenticated message to the SDP client 200, which is the accepting host (AH) (S39).

[0069] The IH service message can be used to provide the initiating host (IH) with the IP address and available service list of the accepting host (AH), and the IH authenticated message can be used to convey the initiating host's (IH) request to accept the connection to the accepting host (AH).

[0070] FIG. 4 is a flowchart illustrating an access process of an information security method according to another embodiment of the present disclosure.

[0071] The access process of this embodiment is an SDP access process for using an optional handshake, and can be performed after the onboarding process described above with reference to Fig. 2. The access process of this embodiment uses an extended EDHOC handshake. That is, in the SDP environment configuration process, the EDHOC handshake is used instead of the TLS handshake, and particularly, when the EDHOC handshake is used in the SDP access process, the SPA packet and the first EDHOC message (Message_1) are combined to minimize delay time and message size and ensure efficiency.

[0072] 4, in the EDHOC handshake process (S40), the SDP client 100, which is an initiating host, can transmit an SPA packet combined with an EDHOC message to the SDP controller 300. That is, the SDP client 100 can transmit an SPA packet combined with a first message (message_1), which is an EDHOC message, to the SDP controller 300 (S41). The SDP controller 300 can receive the SPA packet combined with the first message (message_1) from the SDP client 100 and verify the received SPA packet (S41a).

[0073] When the verification of the SPA packet is completed normally, the SDP controller 300 can open a mutual TCP connection with the SDP client 100 (S42).

[0074] Then, the SDP controller 300 processes the EDHOC handshake with the first message, and after setting up a security session between the SDP controller 300 and the SDP client 100, can transmit a second message (message_2) related thereto to the SDP client 100 (S43). Also, the SDP controller 300 can receive a third message (message_3) from the SDP client 100 as a response to the second message (S44).

[0075] After the security session setup is completed, the SDP client 100, which is the initiating host, sends a login request message including credentials to the SDP controller 300 to inform the SDP controller 300 that it is active, and in response thereto, can receive a login response message from the SDP controller 300 (S47).

[0076] The SDP controller 300 then transmits an IH service message to the SDP client 100, which is the initiating host (IH) (S48), and can transmit an IH authenticated message to the SDP client 200, which is the accepting host (AH) (S49).

[0077] FIG. 5 is an example diagram of an SPA message format for an extended EDHOC handshake that can be adopted in the information security method of FIG.

[0078] 5, for the extended EDHOC handshake, the message packet of the SPA message to which the first EDHOC message is bound may include an IP header 510, a TCP header 520, and a TCP payload 530. The size of the IP header 510 may be 20 bytes, the size of the TCP header 520 may be 20 bytes, and the size of the TCP payload 530 may be 1460 bytes.

[0079] In the information security method of this embodiment, the first EDHOC message can simply be combined with a general SPA message format, but is not limited to this, and specific data elements of the first EDHOC message can replace or omit duplicated data elements among the data elements of the SPA message.

[0080] A typical SPA message format is shown in Table 2 below.

[0081] [Table 2]

[0082] HOTP (HMAC-based one-time password) can refer to the HMAC-based hashed one-time password algorithm. HMAC stands for hash-based message authentication code. Message type and message string may be optional (op) fields.

[0083] The first EDHOC message format that can be adopted in the information protection method of this embodiment is shown in Table 3 below.

[0084] [Table 3]

[0085] According to this embodiment, by combining the SPA and the first EDHOC message, it is possible to minimize the network delay time required for object authentication and key exchange.

[0086] In addition, according to the present embodiment, encryption can be provided for data elements that require security among data elements of the first EDHOC message transmitted in plain text. For example, the SPA can be encrypted with the SPA encryption key exchanged during the onboarding process.

[0087] Furthermore, according to this embodiment, the key material of the temporary public key (G_X) used to generate the application key is included in the SPA and encrypted, thereby improving the security level. The temporary public key (G_X) may be a temporary public key derived by scalar multiplication of a shared secret (G) shared by the SDP client and the SDP controller and a random number of a predetermined bit (bit), for example, a 16-bit random number, generated by the SDP client. Since the temporary public key (G_X) is generated based on a random number, it is possible to prevent a replay attack.

[0088] The SPA message format for such an extended EDHOC handshake (hereinafter referred to as the "extended SPA message format") is shown in Table 4 below.

[0089] [Table 4]

[0090] The extended SPA message format in Table 4 does not have a nonce field, which is a data field for preventing reuse and replay attacks of SPA packets. That is, the extended SPA message format omits the nonce to improve the security level, and instead of the nonce, the public key material of the G_X field of the first EDHOC message format can be included in the message format and encrypted.

[0091] Thus, according to this embodiment, the SDP client can omit data elements that may be duplicated among the data elements of the SPA and the first EDHOC message, and such substitution or combination of specified fields can improve security performance, reduce network bandwidth, and reduce memory usage.

[0092] The first EDHOC message combined SPA message format that can be adopted in the information security method of this embodiment is shown in Table 5 below.

[0093] [Table 5]

[0094] According to the above embodiment, the handshake protocol for configuring the SDP environment can be designed to support three versions, TLS, EDHOC, and extended EDHOC. Also, a configuration of handshake parameters can be provided so that the SDP client can selectively use a desired handshake protocol. Furthermore, by combining the above-mentioned SPA and first EDHOC messages, it is possible to minimize network delay time and reduce memory usage.

[0095] FIG. 6 is a flow chart for explaining the EDHOC protocol that can be adopted in the information security system of FIG.

[0096] 6, the EDHOC protocol is a lightweight handshake protocol designed to set up security sessions between devices in resource-limited environments. The EDHOC protocol may be performed through message exchanges between an initiator 610 and a responder 620. The initiator 610 may be equipped with a pre-shared DH share secret g 601, and similarly, the responder 620 may be equipped with a pre-shared DH share secret g 602.

[0097] First, the initiator 610 may transmit a first EDHOC message including fields related to a method (METHOD), an encryption algorithm list (SUITES_I), a temporary public key (G_X), a connection identifier (C_I), and padding (EAD_1) to the responder 620 (S61). That is, the initiator 610 may transmit an authentication method, an encryption algorithm list, and a DH private key to the responder 620.

[0098] Here, METHOD is a field for specifying static Diffie-Hellman and signature key authentication methods. SUITES_I is a field for a list of encryption algorithms preferred by the sender or initiator 610. G_X is a temporary public key generated by scalar multiplication of the shared secret 601 and a 16-bit random number generated by the initiator. C_I is an identifier for identifying the connection of the EDHOC session. Also, EAD_1 is a field representing external authentication data. The padding can selectively have a CBOR sequence.

[0099] The responder 620 may then encrypt and transmit to the initiator 610 a second EDHOC message (S63), the second EDHOC message including a temporary public key (G_Y) generated by scalar multiplication of the shared secret 602 and a 16-bit random number generated by the responder, and fields related to a connection identifier (C_R), an identifier credential (ID_CRED_R), an electronic signature (signature) or message authentication code (MAC_2), and padding (EAD_2).

[0100] That is, the responder 620 can generate a DH private key and derive a DH shared key to generate an encryption key. Also, the responder 620 can transmit the DH private key for deriving the DH shared key in plain text to the initiator 610. Also, the responder 620 can encrypt credentials, digital signatures, etc. for user authentication and integrity assurance and transmit them to the initiator 610.

[0101] The initiator 610 then derives a DH shared key from the DH private key transmitted in plaintext from the responder 620 to perform message decryption and authentication, generates a session key using the DH shared key, and encrypts a third EDHOC message including fields for credentials (ID_CRED_I), an electronic signature (signature) or message authentication code (MAC_3), and padding (EAD_3) for user authentication and integrity assurance, and transmits it to the responder 620.

[0102] Through the above process, the sensor and the information security device belonging to the Internet of Things cloud can perform an EDHOC handshake and terminate the protocol. In particular, the information security device according to the modified embodiment of the present invention may be configured to bind the ephemeral public key (G_X) in the first EDHOC message to the SPA message. In this case, the ephemeral public key (G_X) field may be omitted in the first EDHOC message.

[0103] FIG. 7 is a block diagram for explaining an SPA message processing process that can be adopted in the information security method of FIG.

[0104] Single Packet Authentication (SPA) refers to a method of opening a port outside a firewall by sending a single pre-defined packet to a closed port before a mutually trusted session is established. Such SPA can prevent brute force and replay attacks on communication nodes such as sensors and low-performance devices in the Internet of Things cloud.

[0105] The message format of SPA may vary between SDP implementations, but it requires that the originator and receiver of a packet share a shared secret and a reliable secure channel.

[0106] 7, the SPA calculation process will be described in more detail. The first SPA calculation unit 700 is a unit having an SPA HOTP calculation function, and receives an SPA OTP shared secret and a signal from an event counter, generates a 160-bit hash through a first HMAC calculation, and generates a 31-bit hash through a unit 710 having a truncation function. The 31-bit hash may be recorded in a hashed one-time password (HOTP) field of the SPA message format 720.

[0107] The second SPA calculation unit is a unit having an SPA HMAC calculation function, and can hash all parameters, including the SPA HMAC key and the data in the remaining fields excluding the HMAC field of the SPA message format 720, the numeric identifier, the validity period, the IP address, the hashed one-time password, the information indicating the message type, and the information specifying the service requested by the IH, to obtain an HMAC value and record it in the HMAC field of the SPA message format 720.

[0108] In addition, the SPA message of the present embodiment may have a form combined with a first EDHOC message 740. In this case, the first EDHOC message may be combined with the SPA message 720 by a message processing API 750 that works with an EDHOC library API (application programming interface) 760. For details of the message format of the SPA message 720, see Table 2.

[0109] FIG. 8 is a schematic block diagram of an information security device according to still another embodiment of the present disclosure.

[0110] 8, the information security device 800 may include a low-performance computer device or communication node belonging to an Internet of Things cloud. The information security device 800 may further include a processor 810, a memory 820, a transceiver device 830, an input interface device 840, an output interface device 850, a storage device 860, or a combination thereof. Each component included in the information security device 800 can be connected by a bus 870 to communicate with each other.

[0111] Furthermore, the components included in the information security device 800 may be connected through separate interfaces or separate buses centered around the processor 810, rather than through a common bus 870. For example, the processor 810 may be connected to at least one of the memory 820, the transceiver device 830, the input interface device 840, the output interface device 850, and the storage device 860 through a dedicated interface.

[0112] The processor 810 may include the above-mentioned first SPA operator, second SPA operator, message processing API, etc. Such a processor may refer to a central processing unit (CPU), a graphics processing unit (GPU), or a dedicated processor on which the method according to the embodiment of the present invention is performed.

[0113] Each of the memory 820 and the storage device 860 may be composed of at least one of a volatile storage medium and a non-volatile storage medium. For example, the memory 820 may be composed of at least one of a read only memory (ROM) and a random access memory (RAM).

[0114] The transceiver 830 may include at least one or more sub-communication systems supporting wireless, mobile, or satellite communication to exchange signals and data with other communication nodes and management servers in the Internet of Things cloud via a network. The other communication nodes may include Internet of Things sensors, etc.

[0115] Here, the network may include a network supporting D2D (device to device) communication, sidelink communication, NR (new radio) communication, etc. Also, the network may include all communication networks that can be formed between on-board units connected via a mobile communication network or a wireless communication network, or devices equipped with on-board units.

[0116] The input interface device 840 may include at least one input means selected from a keyboard, a microphone, a touchpad, a touchscreen, a remote control means, etc., and an input signal processing unit that maps or processes signals input by the at least one input means into pre-stored instructions.

[0117] The output interface device 850 may include an output signal processing unit that maps or processes a signal output under the control of the processor 810 to a pre-stored signal form or level, and at least one output means that outputs a signal or information in the form of vibration, light, sound, heat, etc. according to a signal from the output signal processing unit. The at least one output means may include at least one selected from output means such as a speaker, a display device, a printer, an optical output device, and a vibration output device.

[0118] The processor 810 may execute program commands or software modules having program commands stored in at least one of the memory 820 and the storage device 860. That is, the processor 810 may be configured to perform at least one of the embodiments of the information security scheme described above when the program commands cause the processor 810 to execute the program commands.

[0119] According to the present embodiment, a new information security method using the EDHOC protocol as a lightweight authentication security protocol to replace the TLS handshake for Internet of Things cloud security can be provided. The use of the EDHOC protocol can ensure the security level of the existing TLS 1.3 handshake, while using a smaller message size than the TLS or DTLS protocol, thereby saving network bandwidth and reducing memory usage.

[0120] Also, according to the present embodiment, a handshake protocol extension workflow for configuring an SDP environment can be provided. That is, by adding a handshake parameter that can specify a handshake option that an SPD client intends to use during the SDP onboarding process, efficient security authentication can be realized in various Internet of Things (IoT) environments, and the flexibility of the SDP solution can be improved. Furthermore, by defining a new message format for combining the transmission process of the SPA message and the first EDHOC message, memory usage can be reduced by omitting data elements that can be duplicated between the two messages, and the process required for object authentication and sharing of an application encryption key can be minimized to one round trip time (RTT) to reduce network latency.

[0121] The operation of the method according to the embodiment of the present invention can be realized as a computer readable program or code in a computer readable recording medium. The computer readable recording medium includes any kind of recording device in which information readable by a computer system is stored. In addition, the computer readable recording medium can be distributed among computer systems connected by a network, and the computer readable program or code can be stored and executed in a distributed manner.

[0122] The computer-readable recording medium may also include hardware devices specifically configured to store and execute program instructions, such as ROM, RAM, flash memory, etc. The program instructions may include not only machine code generated by a compiler, but also high-level language code that can be executed by a computer using an interpreter, etc.

[0123] Although some aspects of the invention have been described in the context of an apparatus, they may also be expressed as corresponding method descriptions, where blocks or apparatus correspond to method steps or features of method steps. Similarly, aspects described in the context of a method may be expressed as corresponding blocks or items or features of a corresponding apparatus. Some or all of the method steps may be performed by (or using) a hardware apparatus, such as, for example, a microprocessor, a programmable computer, or an electronic circuit. In some embodiments, at least one or more of the most important method steps may be performed by such an apparatus.

[0124] In embodiments, a programmable logic device (e.g., a field programmable gate array) may be used to perform some or all of the functions of the methods described herein. In embodiments, a field programmable gate array may work in conjunction with a microprocessor to perform one of the methods described herein. In general, it is preferred that the methods are performed by some hardware device.

[0125] The scope of the present disclosure includes software or machine-executable instructions (e.g., operating systems, applications, firmware, programs, etc.) that cause a device or computer to perform operations according to the methods of the various embodiments, and non-transitory computer-readable medium on which such software or instructions are stored and executable on a device or computer.

[0126] Although the present invention has been described above with reference to preferred embodiments, those skilled in the art will understand that the present invention can be modified and changed in various ways without departing from the spirit and scope of the present invention as set forth in the claims below.

Claims

1. A software-defined perimeter (SDP) based information protection method for Internet of Things cloud security, comprising: receiving an onboarding request message via an identity token from an SDP client, which is an initiating host, by an SDP controller, the onboarding request message including information requesting authentication of the SDP client and a handshake parameter for specifying a handshake protocol in an SDP access process; and issuing, by said SDP controller, an SDP client credential that matches said handshake parameters.

2. communicating said SDP client credentials to said SDP client; The SDP-based information protection method of claim 1 , further comprising the step of: receiving a response of receipt of the SDP client credential from the SDP client.

3. The SDP-based information protection method of claim 1 , wherein the handshake parameters include handshake parameter values ​​that specify a TLS handshake protocol, an EDHOC handshake protocol, and an extended EDHOC handshake protocol.

4. The SDP-based information protection method of claim 3 , further comprising the step of using a TLS handshake as a default if the handshake parameters are not specified.

5. 2. The SDP-based information protection method of claim 1, wherein the SDP client credentials include a handshake encryption key, a handshake certificate, an SPA encryption key, and an SPA hash-based message authentication code (HMAC) key.

6. 2. The SDP-based information protection method of claim 1, further comprising the step of including a Diffie-Hellman (DH) shared secret for generating a DH private key in the SDP client credential.

7. receiving an SPA packet from the SDP client; establishing an open TCP connection between the SDP controller and the SDP client via the SPA packets; receiving a first EDHOC message from the SDP client; The SDP-based information protection method of claim 1 , further comprising:

8. 8. The SDP-based information protection method according to claim 7, wherein the steps of receiving an SPA packet and receiving a first EDHOC message include receiving an SPA packet to which the first EDHOC message is combined.

9. 9. The SDP-based information protection method according to claim 8, wherein the SPA packet to which the first EDHOC message is bound includes an IP header, a TCP header, and a TCP payload, where the TCP payload includes the SPA message and the EDHOC message.

10. 9. The SDP-based information protection method according to claim 8, further comprising the step of encrypting data elements of the first EDHOC message that require security.

11. combining a SPA message of said SPA packet and said first EDHOC message; 9. The SDP-based information protection method according to claim 8, further comprising the step of omitting data elements of the first EDHOC message that may overlap with data elements of the SPA message when generating the SPA packet through the combining step.

12. validating the SPA packet; if the SPA packet is verified, processing an EDHOC handshake with the first EDHOC message; 9. The SDP-based information protection method of claim 8, further comprising the step of: if the EDHOC handshake is processed, establishing a security session between the SDP client and the SDP controller.

13. receiving a Login Request message from the SDP client after the security session has been established, the Login Request message including the SDP client credentials; The method of claim 12, further comprising: verifying that the SDP client is active through the login request message.

14. transmitting an initiating host service message to the SDP client; 14. The SDP-based information protection method of claim 13, further comprising the step of: communicating the initiating host authentication message to another SDP client that is an accepting host.

15. A software-defined perimeter (SDP) based information protection device for Internet of Things cloud security, comprising: instructions stored in a memory or storage device; A processor mounted on the SDP controller for executing the instructions; by the processor receiving an onboarding request message via an identity token from an SDP client that is an initiating host, the onboarding request message including information requesting authentication of the SDP client and a handshake parameter for specifying a handshake protocol in an SDP access process; and issuing, by said SDP controller, an SDP client credential suitable for said handshake parameters.

16. 16. The SDP-based information protection apparatus of claim 15, wherein the handshake parameters include handshake parameter values ​​that specify a TLS handshake protocol, an EDHOC handshake protocol, and an extended EDHOC handshake protocol.

17. receiving, by the processor, an SPA packet from the SDP client; establishing, by the processor, an open TCP connection between the SDP controller and the SDP client via the SPA packets; 16. The SDP-based information protection device of claim 15, further comprising the step of: receiving, by said processor, a first EDHOC message from said SDP client.

18. 20. The SDP-based information protection device according to claim 17, wherein the steps of receiving the SPA packet and receiving the first EDHOC message by the processor include receiving an SPA packet to which the first EDHOC message is combined.

19. 20. The SDP-based information protection device according to claim 18, wherein the SPA packet to which the first EDHOC message is bound includes an IP header, a TCP header, and a TCP payload, where the TCP payload includes the SPA message and the EDHOC message.

20. 20. The SDP-based information protection device of claim 17, further comprising the step of: omitting, by the processor, data elements of the first EDHOC message that may overlap with data elements of the SPA message when generating the SPA packet.

Images