SDP-based information protection method and apparatus 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 disclosing 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 new single packet authorization (SPA) clients to the SDP environment, and an access process for sending messages between objects. The access process uses a transport layer security (TLS) handshake and protects 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 pre-defined packet is sent to a closed port, and the port is opened outside the firewall, preventing brute force attacks and replay attacks. In this case, the SPA message format may vary depending on the implementation method of SDP, but the packet creator and receiver must share a shared secret and a reliable security channel.

[0004] Also, while SDP is a lightweight handshake protocol designed for setting up security sessions between devices in resource-constrained environments, it promises smaller message sizes than TLS handshakes, which still make it 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, and to devices based on low-performance computing power 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 techniques, 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 the EDHOC (Ephemeral Diffie-Hellman Over COSE) protocol, which is lighter than the 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 the steps of receiving, by an SDP controller, 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 the SDP access process), and issuing, by the SDP controller, SDP client credentials suitable for the handshake parameters.

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

[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 receiving an SPA packet from the SDP client, establishing 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 attached.

[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 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 the steps of receiving a login request message including the SDP client credentials from the SDP client after the security session setup is completed, and 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: delivering an initiating host service message to the SDP client; and delivering an initiating host authentication message to another SDP client that is an accepting host.

[0023] According to another aspect of the present disclosure, there is provided an SDP-based information protection device for Internet of Things cloud security, the SDP-based information protection device including instructions stored in a memory or a storage device, and a processor mounted on an SDP controller for executing the instructions. The SDP controller may perform the following steps: receiving, by the processor, an onboarding request message from an SDP client serving as an initiating host via an identity token (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 issuing, by the SDP controller, SDP client credentials suitable for the handshake parameters.

[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, the 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. [Effects 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 memory usage.

[0031] Furthermore, according to the present disclosure, it is possible to provide scalability of the 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 a different handshake protocol, the EDHOC protocol, while maintaining the existing SDP environment configuration function in Internet of Things cloud security, i.e., the TLS handshake. It is also possible to provide a workflow that allows the selection of a different handshake protocol, the lightweight EDHOC protocol, while ensuring security at an existing TLS level, for example, the TLS 1.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 operates flexibly in various IoT environments. [Brief explanation of the drawings]

[0032] [Figure 1] 1 is a schematic diagram of a software-defined perimeter (SDP) architecture that can employ an information security method according to an embodiment of the present disclosure. [Figure 2] 1 is a flowchart illustrating an onboarding process of an information security system according to an embodiment of the present disclosure. [Figure 3] 1 is a flowchart illustrating an access process of an information security method according to an embodiment of the present disclosure. [Figure 4] 10 is a flowchart illustrating an access process of an information security method according to another embodiment of the present disclosure. [Figure 5] 5 is an exemplary diagram of an SPA message format for an extended EDHOC handshake that can be adopted in the information security method of FIG. 4. [Figure 6] 5 is a flowchart for explaining an EDHOC protocol that can be adopted in the information security system of FIG. 4. [Figure 7] 5 is a block diagram illustrating an SPA message processing process that can be adopted in the information security method of FIG. 4. [Figure 8] 10 is a schematic block diagram of an information security device according to still another embodiment of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0033] Since the present invention can be modified in various ways and can have various embodiments, specific embodiments are shown in the drawings and described in detail, but this does not limit the present invention to the specific embodiments, and it should be understood that the present invention includes all modifications, equivalents, and alternatives that fall within 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 these terms. These terms are used only to distinguish one component from another. For example, a first component can be referred to as a second component, and similarly, a second component can be referred to as a first component, without departing from the scope of the present 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 that there may 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 specific embodiments and are not intended to limit the present invention. The singular expressions include the plural expressions unless the context clearly dictates otherwise. In this application, the terms "comprise" 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 possibility of 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 one 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, preferred embodiments 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, to facilitate overall understanding, the same components on the drawings will be given the same reference numerals, and duplicate descriptions of the same components will be omitted.

[0040] FIG. 1 is a schematic diagram of a software-defined perimeter (SDP) architecture that can employ an information security method according to one embodiment of the present disclosure.

[0041] SDP is an information protection method that blocks potential attacks through authentication and encryption without disclosing the protected information to the outside world. SDP is used to protect networks with the aim of minimizing vulnerabilities and the risk of sensitive information theft 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 grants access to resources according to their permissions. 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 and 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 functionality as and represent the plurality of second SDP hosts.

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

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

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

[0046] Each object of the SDP solution included in the SDP architecture can perform key exchange for mutual authentication and 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 an SDP environment, and messages sent between objects can be protected using asymmetric key encryption. An SPA client, like an SDP client, may contain an initiating host and an accepting host.

[0049] The SDP onboarding process 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 receives an ID token from the ID provider 400 through user authentication (S22) (S23).

[0051] Then, the SDP client 100 can request SDP client authentication through the ID token from the SDP controller 300. That is, when transmitting the ID token, the SDP client 100 can transmit an onboard request message to the SDP controller 300. When transmitting the ID token, the SDP client 100 can transmit a handshake parameter specifying the type of handshake protocol for the 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 issue new 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 SDP controller 300 in response to the receipt of the credentials (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, 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 SDP onboarding process using a 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 also a binary data serialization format based on JSON that can be used to more succinctly transmit data objects containing 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 this embodiment, a lightweight authentication security protocol and workflow can be configured in the SDP solution to replace the TLS handshake. That is, a workflow can be provided that uses the EDHOC protocol as a lightweight authentication security protocol to replace the TLS handshake.

[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, allowing for efficient security session setup.

[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] Next, 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 also be referred to as a first EDHOC message.

[0066] If the SPA packet is verified, the SDP controller 300 processes the EDHOC handshake using the first message, establishes a security session between the SDP client 100 and the SDP controller, and then transmits a related second message (message_2) to the SDP client 100 (S35). The SDP controller 300 can also 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 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 (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) connection acceptance request to the accepting host (AH).

[0070] FIG. 4 is a flowchart illustrating an access process of an information security system 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 Figure 2. The access process of this embodiment uses an extended EDHOC handshake. That is, the EDHOC handshake is used instead of the TLS handshake in the SDP environment configuration process. In particular, 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 the 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] If the verification of the SPA packet is completed successfully, the SDP controller 300 can open a mutual TCP connection with the SDP client 100 (S42).

[0074] Next, the SDP controller 300 processes the EDHOC handshake using the first message, sets up a security session between the SDP controller 300 and the SDP client 100, and then transmits a second message (message_2) related thereto to the SDP client 100 (S43). In addition, 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 employed in the information security scheme of FIG.

[0078] 5, for an extended EDHOC handshake, the message packet of the SPA message combined with the first EDHOC message 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 this 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 by a random number of a predetermined number of bits (e.g., a 16-bit random number) generated by the SDP client. Because the temporary public key (G_X) is generated based on a random number, replay attacks can be prevented.

[0088] The SPA message format for such an extended EDHOC handshake (hereinafter referred to as "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 SPA packet reuse and replay attacks. That is, the extended SPA message format omits the nonce to improve the security level, and instead of the nonce, the public key material in 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 overlapping data elements from the SPA and the first EDHOC message, and by replacing or combining certain fields in this way, it is possible to 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 system of this embodiment is shown in Table 5 below.

[0093] [Table 5]

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

[0095] FIG. 6 is a flowchart 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 for setting up security sessions between devices in resource-constrained 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_I) to the responder 620 (S61). That is, the initiator 610 may transmit the authentication method, the encryption algorithm list, and the DH private key to the responder 620.

[0098] Here, METHOD is a field for specifying the static Diffie-Hellman and signature key authentication methods. The encryption algorithm list (SUITES_I) is a field for listing the encryption algorithms preferred by the sender or initiator 610. The temporary public key (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. The connection identifier (C_I) is an identifier that identifies the connection of the EDHOC session. Furthermore, padding (EAD_1) is a field that represents external authentication data. The padding can optionally have a CBOR sequence.

[0099] The responder 620 can then encrypt and transmit to the initiator 610 a second EDHOC message (S63) that includes 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, as well as fields for a connection identifier (C_R), an identifier credential (ID_CRED_R), an electronic 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. The responder 620 can also transmit the DH private key for deriving the DH shared key in plain text to the initiator 610. The responder 620 can also 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 decrypt and authenticate the message, generates a session key using the DH shared key, and encrypts and transmits to the responder 620 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.

[0102] Through the above process, sensors and information security devices belonging to the Internet of Things cloud can perform an EDHOC handshake and complete the protocol. In particular, the information security device according to a modified example of this embodiment may be configured to combine the ephemeral public key (G_X) in the first EDHOC message with the SPA message. In this case, the ephemeral public key (G_X) field may be omitted from the first EDHOC message.

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

[0104] Single Packet Authentication (SPA) is 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. This type of 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 depending on the implementation of SDP, but it is essential that the originator and receiver of the 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 an event counter signal, generates a 160-bit hash through a first HMAC calculation, and generates a 31-bit hash through a truncation unit 710. The 31-bit hash may be recorded in a hashed one-time password (HOTP) field of an 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 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, information indicating the message type, and 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 this embodiment may be 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 in conjunction 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, an information security apparatus 800 may include a low-performance computer device or communication node belonging to an Internet of Things cloud. The information security apparatus 800 may further include a processor 810, a memory 820, a transceiver 830, an input interface device 840, an output interface device 850, a storage device 860, or a combination thereof. The components included in the information security apparatus 800 are connected to each other by a bus 870 to communicate with each other.

[0111] Furthermore, the components included in the information security device 800 may be connected via individual interfaces or individual buses centered around the processor 810, rather than via 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 via a dedicated interface.

[0112] The processor 810 may include the above-described first SPA operator, second SPA operator, message processing API, etc. The processor 810 may refer to such 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 communications 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 that supports device-to-device (D2D) communication, sidelink communication, new radio (NR) 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 between 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, 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 into 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 the 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 above-described information security scheme embodiments when the program commands are executed by the processor 810.

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

[0120] According to this embodiment, an extended handshake protocol workflow for configuring an SDP environment can be provided. That is, by adding a handshake parameter that allows an SDP client to specify the handshake option it wants to use during the SDP onboarding process, efficient security authentication can be achieved in various Internet of Things (IoT) environments, improving the flexibility of the SDP solution. Furthermore, by defining a new message format for combining the transmission processes of the SPA message and the first EDHOC message, memory usage can be reduced by omitting data elements that may be duplicated between the two messages, and network latency can be reduced by minimizing the processes required for object authentication and application encryption key sharing to one round trip time (RTT).

[0121] The operations of the methods according to the embodiments of the present invention can be realized as a computer-readable program or code stored in a computer-readable recording medium. The computer-readable recording medium includes any type of recording device that stores information readable by a computer system. The computer-readable recording medium can also be distributed among computer systems connected via a network, allowing the computer-readable program or code to be stored and executed in a distributed manner.

[0122] The computer-readable recording medium may also include a hardware device specifically configured to store and execute program instructions, such as a ROM, a RAM, a flash memory, etc. The program instructions may include not only machine language 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 present invention have been described in the context of an apparatus, they may also be expressed as a corresponding method description, where a block or apparatus corresponds to a method step or feature of a method step. Similarly, aspects described in the context of a method may be expressed as a corresponding block or item, or feature 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 significant 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 operate in conjunction with a microprocessor to perform one of the methods described herein. In general, it is preferred that the methods be 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 various embodiments, and non-transitory computer-readable media 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, it will be understood by those skilled in the art that various modifications and variations of the present invention can be made 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 that is an initiating host, by an SDP controller (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 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: receiving a response to receive 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 ​​specifying 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 in the SDP client credential for generating a DH private key.

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 of claim 8, wherein the SPA packet to which the first EDHOC message is attached includes an IP header, a TCP header, and a TCP payload, and the TCP payload includes the SPA message and the EDHOC message.

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

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

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 SDP-based information protection method of claim 12, further comprising: confirming 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 (ID) 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); The SDP controller selects an SDP class suitable for the handshake parameters. and issuing a client credential to the SDP-based information protection device.

16. 16. The SDP-based information protection device of claim 15, wherein the handshake parameters include handshake parameter values ​​specifying 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. 18. The SDP-based information protection device of claim 17, wherein the steps of receiving the SPA packet and receiving the first EDHOC message by the processor include receiving the SPA packet to which the first EDHOC message is combined.

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

20. 20. The SDP-based information protection device of claim 19, 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