The present disclosure relates to an authentication processing technique and, in particular, to a method and apparatus for processing sharing authentication in an information-centric network environment.
Researches for realizing an in-networking processing technique in an information-centric network (ICN) environment are actively conducted by IETF COINRG and other organizations.
The in-networking processing technique is a type of network-distributed computing that utilizes a computing resource of a network communication device like a router for a computation offloading service. When a user's device (for example, IoT terminal) requests operation processing to a network, a random in-network device, which is dynamically selected in a routing/forwarding process, processes the request and responds to the user's device by sending a corresponding result.
In such an environment, securing a cryptographic authentication means, which prevents an unauthorized user from illegally occupying or abusing computing resources of network-distributed processing devices, is very important to provide a safe in-networking processing service.
According to the traditional authentication method, a server and a user share secret information in advance, and the secret information is verified between the server and the user when the user accesses a network device. In this case, the server is a verifier, and the user is a prover. Most of the conventional internet authentication methods have a “1 verifier-u provers” structure. One authentication server (verifier) at the center verifies a multiplicity of (u) users (provers). On the other hands, in-network authentication has a “n verifiers-u provers” structure. Each of N network devices (verifiers), which are independent of each other, verifies each of u users (provers).
In such a structure, that is, in an in-network distributed processing environment with characteristics of “1-way, low-delay, dynamic selection of an in-network processing device, and division operation processing”, the conventional technique has the following limitations.
First, regarding to the 1-way, the information-centric network provides a 2-way request-response communication protocol without concept of session. When an in-network processing device (verifier) receives a prover (user)'s request, an immediate authentication, that is, 1-way authentication is required. On the other hand, the conventional technique requires 3-way or 4-way handshaking, thereby causing not only authentication traffic but also a problem of authentication session management.
Second, regarding to the low-delay, the information-centric network aims for a low-delay communication service. An in-network processing device (verifier) demands local authentication whereby a user's request is immediately authenticated on the spot. A remote authentication method that sends a query to a central server for authentication causes not only an increase of delay time but also a problem of traffic load.
Third, regarding to the dynamic selection, an in-network device (verifier) is dynamically determined according to a routing/forwarding strategy. In such an environment, the authentication method of a prior art need to manage authentication databases of u provers at every processing device, synchronization the authentication databases, and maintain the authentication databases. This is inapplicable to a communication device. Accordingly, a new authentication method is necessary which can identify and authenticate a user without requiring a device (verifier) to maintain user information.
Fourth, regarding to the division operation processing, the in-network processing device may divide a user's operation request into sub operations and request processing sub operations to a new in-network processing device. Here, a “user-device operation processing chain” is generated. Authentication is necessary which may provide connectivity between a prover (user or current processing device) and a verifier (new processing device) in an operation processing chain. However, a challenge-response authentication method of a prior art cannot provide such authentication.
To address the above-discussed deficiencies, it is a primary object to provide a method and apparatus for an in-network threshold secret sharing authentication and key distribution implementing such features as 1-way authentication, dynamic sharing authentication, low-delay local authentication, division operation-connected authentication.
Also, the present disclosure aims to provide a method and apparatus for processing threshold secret sharing authentication in an ICN environment.
The technical objects of the present disclosure are not limited to the above-mentioned technical objects, and other technical objects that are not mentioned will be clearly understood by those skilled in the art through the following descriptions.
According to one aspect of the present disclosure, a system for a secret sharing authentication may be provided. The system may include a secret sharing information management server, a client device, and a network device. The secret sharing information management server may store and manage an authentication key capable of being used for secret sharing authentication, by dividing it into a first secret sharing key shard and a second secret sharing key shard, and allocate the first and second secret sharing key shards. The client device may receive the first secret sharing key shard from the secret sharing information management server and construct an interest packet by using the first secret sharing key shards. The network device may receive the second secret sharing key shard from the secret sharing information management server, and process the interest packet received from the client device on the basis of an ICN(Information Centric Networking) method by performing secret sharing authentication using the second secret sharing key shard and the first secret sharing key shard comprised in the interest packet.
The features briefly summarized above with respect to the present disclosure are merely exemplary aspects of the detailed description below of the present disclosure, and do not limit the scope of the present disclosure.
Hereinbelow, exemplary embodiments of the present disclosure will be described in detail with reference to the accompanying drawings such that the present disclosure can be easily embodied by one of ordinary skill in the art to which this invention belongs. However, the present disclosure may be variously embodied, without being limited to the exemplary embodiments.
In the description of the present disclosure, the detailed descriptions of known constitutions or functions thereof may be omitted if they make the gist of the present disclosure unclear. Also, portions that are not related to the present disclosure are omitted in the drawings, and like reference numerals designate like elements.
In the present disclosure, when an element is referred to as being “coupled to”, “combined with”, or “connected to” another element, it may be connected directly to, combined directly with, or coupled directly to another element or be connected to, combined directly with, or coupled to another element, having the other element intervening therebetween. Also, it should be understood that when a component “includes” or “has” an element, unless there is another opposite description thereto, the component does not exclude another element but may further include the other element.
In the present disclosure, the terms “first”, “second”, etc. are only used to distinguish one element, from another element. Unless specifically stated otherwise, the terms “first”, “second”, etc. do not denote an order or importance. Therefore, a first element of an embodiment could be termed a second element of another embodiment without departing from the scope of the present disclosure. Similarly, a second element of an embodiment could also be termed a first element of another embodiment.
In the present disclosure, components that are distinguished from each other to clearly describe each feature do not necessarily denote that the components are separated. That is, a plurality of components may be integrated into one hardware or software unit, or one component may be distributed into a plurality of hardware or software units. Accordingly, even if not mentioned, the integrated or distributed embodiments are included in the scope of the present disclosure.
In the present disclosure, components described in various embodiments do not denote essential components, and some of the components may be optional. Accordingly, an embodiment that includes a subset of components described in another embodiment is included in the scope of the present disclosure. Also, an embodiment that includes the components described in the various embodiments and additional other components are included in the scope of the present disclosure.
Hereinafter, embodiments of the present disclosure will be described with reference to the accompanying drawings.
Referring to
Centric Networking) environment and include a secret sharing information management server 11, a client device 13 and a network device 15.
The secret sharing information management server 11 may manage and divide a secret key capable of being used for secret sharing authentication into secret sharing key shards. Particularly, a secret sharing authentication system 10 according to an embodiment of the present disclosure may be constructed in an in-networking processing environment. In order to implement threshold secret sharing, secret sharing key shards may be configured by dividing a secret key according to the number (n) of processing devices installed in the secret sharing authentication system 10, and may also be possessed by being allocated to each processing device. Thus, each processing device installed in the secret sharing authentication system 10 may independently perform authentication or verification without intervention of a central server during the authentication process. Based on this, the secret sharing information management server 11 may generate and mange an available pool of secret sharing key shards that are to be allocated to each processing device, that is, the client device 13 and the network device 15, which are installed in the secret sharing authentication system 10. In addition, the secret sharing information management server 11 may receive a request of secret sharing information from the client device 13 or the network device 15 and may also allocate and provide secret key shards in an available pool.
Furthermore, in the secret sharing authentication system 10, a client device may function as a prover requesting authentication, and the network device 15 may function as a verifier verifying the requested authentication. Thus, in the secret sharing authentication system 10, u provers, that is, u client devices 13 are installed, n verifiers, that is, n network devices 15 are installed, and one secret sharing information management server 11 is installed. In addition, the secret sharing information management server 11 is so constructed that a secret key 200 (refer to
The client device 13 may be an apparatus that generates and transmits an interest packet in an ICN environment. Particularly, the client device 13 may request a key sharing key shard to the secret sharing information management server 11 and construct a secret sharing authentication token including a secret sharing key shard 201 received from the secret sharing information management server 11. In addition, the client device 13 may generate an interest packet including a secret sharing authentication token.
The network device 15 is an apparatus that receives an interest packet from the client device 13 in an ICN environment and transmits the packet to an information provider. A network device may include a router. Particularly, the network device 15 may request a key sharing key shard 203 to the secret sharing information management server 11 and store the secret sharing key shard 203 received from the secret sharing information management server 11. In addition, the network device 15 may confirm a secret sharing authentication token included in an interest packet and perform secret sharing authentication. Particularly, the network device 15 may extract a secret sharing key shard 302 included in a secret sharing authentication token 301 (refer to
Furthermore, in case a split operation is required for secret sharing authentication, the network device 15 may request split operation processing to another network device and process a split operation by receiving a result.
Hereinafter, detailed operations of a secret sharing authentication system 10 will be described in detail.
<Initial Settings of Secret Sharing Information Management Server>
Referring to
Specifically, the secret sharing information management server 11 may generate server parameters necessary for distributed authentication using secret sharing methods like a secret key, a polynomial and a threshold (S410). A secret sharing polynomial may be expressed by Equation 1 below.
P
t(x)=a0+a1x+a2x2+. . . +atxt Equation 1
Here, a coefficient may be [a0, a1, . . . , at], which may be generated as a random value.
A secret key used for secret sharing may be expressed by Equation 2 below.
a
0
=P
t(0) Equation 2
Here, t may be the minimum number of secret sharing key shards necessary for reconstructing a secret key. It may be set to 3 and above. t may be set to be equal to or less than the sum of the number (u) of client devices 13 and that (n) of network devices 15.
Server parameters necessary for distributed authentication may be as follows.
q: Decimal value of modulo operation (u+n<q)
r: Random value for masking secret sharing key shards to be distributed, ( )
p: Decimal value of modulo operation satisfying the conditional expression (p=q*r+1)
Multiplicative group generator of a finite field satisfying the conditional expression
g1r, g2q: Secret sharing shard masking parameter, 0
: Validation parameter for distributed secret sharing shards
Next, the secret sharing information management server 11 may generate an information pool that divides a secret key (a0) into secret sharing shards (S420). Herein, an information pool of the client device 13 and an information pool of the network device 15 may be separately constructed and managed. For example, an information pool of the client device 13 may be constructed by the following operation.
First, the secret sharing information management server 11 may calculate a random value (xi) for secret sharing ID of the i-th client device 13 (S421, refer to
Likewise, the secret sharing information management server 11 may construct an information pool of a network device by the following operation.
First, the secret sharing information management server 11 may calculate a random value (xj) for secret sharing ID of the j-th network device 15. Herein, a random value (xj) for secret sharing ID may be set to {umlaut over (|)}u (S424, refer to 4C). For this, the secret sharing information management server 11 may calculate a random value (xi) for secret sharing ID of the client device 13 and then a random value (xj) for secret sharing ID of the network device 15. In addition, the secret sharing information management server 11 may calculate a secret sharing key shard (f(xj)=Pt(xj)) corresponding to ID (xj) of each network device 13 (S425) and then calculate a secret key (g1rf(xj)mod p) masked with g1r(S426).
By the above-described operation, the secret sharing information management server 11 may construct an information pool corresponding to a secret sharing ID (xi) of the client device 13 and an information pool corresponding to a secret sharing ID (xj) of the network device 15.
Referring to
Specifically, the secret sharing information management server 11 may generate t-2 server secret sharing shard sets (S−2) to be distributed to the network device 15 and a Lagrange interpolation coefficient (L−2) of the server secret sharing shard sets (S−2). Server secret sharing shard sets (S−2) and a Lagrange interpolation coefficient (L−2) may be generated based on Equation 3 and Equation 4 respectively.
<Registration of Client Device and Network Device to Secret Sharing Information Management Server>
The client device 13 or the network device 15 may request registration to the secret sharing information management server 11 through a request-response protocol with the secret sharing information management server 11 and may receive a secret sharing key shard as a corresponding response.
Correspondingly, the secret sharing information management server 11 may allocate secret sharing key shards from an information pool of the client device 13 (S503). In addition, the secret sharing information management server 11 may execute encryption and electronic signature for secret sharing key shards and construct a data packet including encrypted and electronically signed secret sharing key shards (S504). Then, the secret sharing information management server 11 may deliver a data packet as a response to the client device 13 (S505). Correspondingly, the client device 13 may receive the data packet from a network. Here, the data packet may include the name of the client device 13 or a user, signature, a user's certificate and the like.
In the step S506, the client device 13 may distinguish whether or not a data packet received from the secret sharing information management server 11 is a response message. In the step S507, the client device 13 may verify a signature by using a server certificate included in a data packet and may decode an encrypted secret sharing key shard by using a secret key of the client device 13. Then, if a result is judged to be verified in the step S508, the client device 13 may manage and store the secret sharing key shard thus extracted and the server certificate into a secret sharing authentication information DB installed in the client device 13.
An operation of registering the network device 15 to the secret sharing information management server 13 may be configured in the same manner as the above-described operation of registering the client device 13. Specifically, referring to
Correspondingly, the secret sharing information management server 11 may allocate secret sharing key shards from an information pool of the network device 15 (S513). In addition, the secret sharing information management server 11 may execute encryption and electronic signature for secret sharing key shards and construct a data packet including encrypted and electronically signed secret sharing key shards (S514). Then, the secret sharing information management server 11 may deliver a data packet as a response to the network device 15 (S515). Here, the data packet may include the name of the network device 15, an encrypted secret sharing key shard, a signature and a server certificate.
In the step S516, the network device 15 may distinguish whether or not a data packet received from the secret sharing information management server 11 is a response message. In the step S517, the network device 15 may verify a signature by using a server certificate included in a data packet and may decode an encrypted secret sharing key shard by using a secret key of the network device 15. Then, if a result is judged to be normal in the step S518, the network device 15 may manage and store the secret sharing key shard thus extracted and the server certificate into a secret sharing authentication information DB installed in the network device 13.
<Distribution of Secret Sharing Key Shards>
Distributing secret sharing key shards may be a detailed operation of the above-described operations (S503, S513) of allocating secret sharing key shards in an information pool of the client device 13 or the network device 15.
Referring to
Then, if it is identified as a certificate of the client device 13 (S605-a), the secret sharing information management server 11 may allocate an unused secret sharing key shard from an available secret sharing information pool of the client device 13 to the client device 13, and the secret sharing key shard may be registered and managed in the secret sharing information management server 11 (S606). The secret sharing information management server 11 may encrypt an allocated secret sharing key shard by a public key of the client device 13 and may construct a response packet signed with a secret key of the server 11 (S607).
If it is identified as a certificate of the network device 15 (S605-b), the secret sharing information management server 11 may allocate an unused secret sharing key shard from an available secret sharing information pool of the network device 15 to the network device 15, and the secret sharing key shard may be registered and managed in the secret sharing information management server 11 (S611). Then, the secret sharing information management server 11 may allocate and mange an initial verifier setting parameter that is necessary for a registered network device 15 to execute secret sharing authentication (S612).
In the step S613, the secret sharing information management server 11 may encrypt an allocated secret sharing key shard and a verifier setting parameter for a network device 15 by a public key of the network device 15 and may construct a response packet signed with a secret key of the server 11 (S614).
In the step S615, the server may transmit a registration response packet, which is generated in the step S607 or S614, to the client device 13 or the network device 15.
<Initial Setting for Threshold Secret Sharing Authentication of Network Device>
As described in the configuration of the secret sharing authentication system 10, the network device 15, which processes a verifying operation by using information received from the secret sharing information management server 11, may calculate and mange a necessary parameter for verification through an initial setting operation in advance. Hereinafter, an initial setting operation of a network device will be described with reference to
Referring to
In the step S702, the network device 15 may distinguish whether or not a received packet is a response packet at a service registration request of the network device 15.
In the step S703, the network device 15 may verify a signature of a response packet by using a server certificate received along with a message and may also decode the response packet by using a secret key of the network device 15.
In the step S704, when decoding is normally executed, the network device 15 may extract a secret sharing key shard (<xnj, g1rf(x
In the step S706, the network device 15 may set an initial state of a threshold secret sharing verifier consisting of (t-1) secret sharing key shards by using secret sharing key shards and an initial verifier setting parameter, which are extracted in the step S705.
<Secret Sharing Authentication Token Construction of Client Device>
Referring to
Furthermore, while a secret sharing authentication token is constructed, the client device 13 may generate an encryption key (kui) (for example, a random value) for message integrity verification between the client device 13 and the network device 15 and also execute masking for the encryption key (kui) by using a masked secret key. Thus, the client device may construct the random key 954 for integrity verification and encryption, as expressed by Equation 8 below.
τ=kuig1ra0 Equation 8
In addition, the client device 13 may add its identifier to an interest packet processing path 955 {PjHash(<xui,g1rf(xui)+g2q>}. Based on this, such an ID may be used to identify a path of a device where an interest packet is processed.
Then, the client device 13 may transmit an interest packet to a network device (S813). <In-Network Processing Service Request and Response Using Secret Sharing Authentication Token>
Referring to
After receiving an interest packet, the network device 15 judges whether or not it is acceptable by using information included in the header of the interest packet (S1002). In case it is not acceptable, the network device 15 forwards the packet (S1003). On the other hand, if it is acceptable in the step S1002, the network device 15 may execute authentication using a secret sharing authentication token (S1004). Authentication using a secret sharing authentication token will be described in detail by referring to
When authentication is succeeded in the step S1004, the network device 15 may process an in-network processing request function based on information included in the header of an interest packet (S1005). Here, if a calculation function execution code or input data of a function is required for processing a request function, a request may be sent to and a response may be received from a calculation function provider or a calculation data provider.
Furthermore, in the step S1005, if split processing of a calculation function is necessary (S1006-Y), a current network device 15 may generate and transmit an interest packet processing request to another network device (15′) (S1007). A detailed operation of constructing and transmitting an interest packet will be described in detail with reference to
Meanwhile, another network device (15′) receiving an interest packet may judge whether or not it is acceptable (S1010) and execute authentication (S1010) and in-network processing (S1011), like in the steps S1002, S1004 and S1005.
In the step S1012, the network device 15 may encrypt a processing result of the step S1005 or the step S1011 by using an encryption key and may respond to a user by constructing a data packet.
In the step S1013, after receiving an encrypted response data packet for an in-network processing request, the client device 13 may decode it by an encryption key and verify its integrity.
<Authentication Using Secret Sharing Authentication Token in Network Device>
As a secret sharing authentication method can reconstruct a secret key (g1ra0) only when the number of secret shards, which can be known, is equal to or greater than a predetermined threshold (t), a verifier should verify whether or not a user has one of valid secret sharing shards (952, 953) necessary for reconstructing the secret key. In a secret sharing authentication system according to an embodiment of the present disclosure, a network device may function as a verifier. Hereinafter, a network device functioning as a verifier will be referred to as a verifier.
In the steps S1101 and S1102, a verifier may receive an interest packet and extract a secret sharing authentication token. Herein, a secret sharing authentication token may include a user's secret sharing key shards. Since a user's secret sharing key shards are distributed after being double-masked by a server with the intent of preventing a secret key from being leaked by the user's conspiracy, a verifier of a network device unmasks them into recognizable secret key shards by using Equation 9 before authentication.
g
1
rf(x
)=((g1rf(x
In the step S1103, a verifier may calculate a secret sharing key shard for a secret sharing ID (952)=xui, of a user (or a client network device in the case of split operation) by using a validation parameter (a dividend of division p, C=(g1ra0, g1ra1, g1rat), which is provided as an initial setting parameter from a secret sharing information management server, as expressed in Equation 10.
In the step S1104, it may be checked whether or not a secret sharing key shard (g1rf(xui)953) extracted in the step S1102 is the same as the value of S′ calculated in the step S1103. Thus, <secret sharing ID, secret sharing key shard> of a user (or a network client device) may be identified, and whether or not it is issued by a secret sharing information management server may be verified.
In the step S1105, a verifier may construct t threshold secret sharing key shards by merging one secret shard <secret sharing ID, secret sharing key shard> of a user or a client device and (t-1) secret sharing key shards that are initially set. In addition, a verifier may reconstruct a calculated threshold sharing secret key (δ) by using the Lagrange interpolation.
In the step S1106, the threshold sharing secret key (δ) that is reconstructed in the step S1105 may be compared with a secret key (g1ra0) received from a secret sharing information management server. Thus, it may be checked whether or not they are identical. Accordingly, a verifier may verify that a client device has a proved secret sharing shard, thereby judging whether or not authentication is succeeded or fails.
In the step S1107, a verifier may extract an integrity verification/encryption key 954 included in a secret sharing authentication token 750 by using a calculation of δ obtained in the step S1106, as expressed in Equation 11 below. The integrity verification/encryption key may be stored and managed in the verifier, that is, a network device.
In the step S1108, an integrity verification code may be calculated by using the integrity verification/encryption key (=kui) 954 extracted in the step S1107, as expressed in Equation 12 below.
Equation 12
mac′ui=Hash(Kuv Function name (911), Random nonce (912), Secret sharing authentication token data (951˜955))
In the step S1109, a verifier may compare an integrity verification code (mac′ui) calculated in the step S1108 and an integrity verification code (mac) 956 included in a secret sharing authentication token 950. Thus, it may be checked whether or not the secret sharing authentication token 950 is reused by an attacker, and the success or failure of authentication may be ultimately determined.
<Interest Packet Construction and Transmittance for Split-Operation Processing in Network Device>
As described above, the construction and transmittance of an interest packet illustrated in
In the steps S1201 and S1202, an operation processor of a network device may generate an interest packet and a secret sharing authentication token for split operation.
In the step S1202, since a split operation processing request is made to execute in-network processing requested by a client device, a secret sharing ID 952 and a secret sharing key shard 953, which are included in a secret sharing authentication token 950, may include an initial user's information.
On the other hand, since integrity verification or an operation connection chain between processing devices is made between a first network device (xnj) and a second network device (xnk), an integrity verification/encryption key ( ) 1231 may be generated and constructed randomly by the first network device. Here, the integrity verification/encryption key 1231 generated by the first network device may be constructed as shown in Equation 13 below.
τ=knjg1ra0 Equation 13
A request processing device path value 1232 of a secret sharing authentication token may be generated by adding a secret sharing ID (xnj) of a first network device to a request processing device path (xui) that is generated by an initial user or a client device. For example, it may be generated by Equation 14 below.
P={Hash(<xui,g1rf(x
In addition, a first network device may generate a hash result, which is obtained by inputting a split operation processing function name 1221, a random nonce 1222, data of a corresponding secret sharing authentication token 951, 952, 953, an integrity verification/encryption key 1231 and a request processing device path 1232, as a message integrity verification code 1233 of the secret sharing authentication token.
Meanwhile, in the step S1203, a first network device may send an interest packet 1200 constructed through the above-described operation, that is, an interest packet 1200 for split-operation processing.
<Operation (or Split Operation) Response Data Packet Processing in Network Device>
As described above, when split processing of a calculation function is required for function processing, the construction and transmittance of an interest packet illustrated in FIG. 12 may be necessary for a current network device (for example, a first network device) to request processing to another network device (for example, a second network device), and the second network device may execute split operation and respond to the first network device by transmitting the result.
Hereinafter, referring to
First, referring to
In the step S1302, a second network device may generate encrypted operation result data 1313 and an integrity verification code 1315 for a response message by fetching a secret key (k) stored inside. In addition, in order to render the traceability of an in-network operation processing chain, a second network device may generate a request processing device path 1314 P={Hash(<xui,g1rf(xui)+g2q>}∥Hash(<xnj,g1rf(xnj)>∥Hash(<xnk,g1rf(xnk)>}, to which a secret sharing ID of the second network device is added.
In the step S1303, a second network device may transmit a response data packet 1310 including in-network processing result to a requester, that is, a first network device (xnj). (If not split-operation processing, as described above, a first network device (xnj) may transmit it to a user client device (xui).)
According to the present disclosure, a method and apparatus for securing a cryptographic authentication means with characteristics of “1-way authentication, dynamic sharing authentication, low-delay local authentication, split operation-connected authentication”, without depending on a centralized authentication server and maintaining user information (DB) at network nodes.
According to the present disclosure, a method and apparatus for minimizing communication service delay and preventing an unauthorized user from illegally occupying or abusing computing resources may be provided, as in-network distributed processing devices may internally perform user authentication immediately after the receipt of a packet.
Effects obtained in the present disclosure are not limited to the above-mentioned effects, and other effects not mentioned above may be clearly understood by those skilled in the art from the following description.
Referring to
Accordingly, the steps of the method or algorithm described in relation to the embodiments of the present disclosure may be directly implemented by a hardware module and a software module, which are operated by the processor 2100, or a combination of the modules. The software module may reside in a storing medium (that is, the memory 2300 and/or the storage 2600) such as a RAM memory, a flash memory, a ROM memory, an EPROM memory, an EEPROM memory, a register, a hard disk, a detachable disk, and a CD-ROM. The exemplary storing media are coupled to the processor 2100 and the processor 2100 can read out information from the storing media and write information on the storing media. Alternatively, the storing media may be integrated with the processor 2100. The processor and storing media may reside in an application specific integrated circuit (ASIC). The ASIC may reside in a user terminal. Alternatively, the processor and storing media may reside as individual components in a user terminal.
The exemplary methods described herein were expressed by a series of operations for clear description, but it does not limit the order of performing the steps, and if necessary, the steps may be performed simultaneously or in different orders. In order to achieve the method of the present disclosure, other steps may be added to the exemplary steps, or the other steps except for some steps may be included, or additional other steps except for some steps may be included.
Various embodiments described herein are provided to not arrange all available combinations, but explain a representative aspect of the present disclosure and the configurations about the embodiments may be applied individually or in combinations of at least two of them. Further, various embodiments of the present disclosure may be implemented by hardware, firmware, software, or combinations thereof When hardware is used, the hardware may be implemented by at least one of ASICs (Application Specific Integrated Circuits), DSPs (Digital Signal Processors), DSPDs (Digital Signal Processing Devices), PLDs (Programmable Logic Devices), FPGAs (Field Programmable Gate Arrays), a general processor, a controller, a micro controller, and a micro-processor.
The scope of the present disclosure includes software and device-executable commands (for example, an operating system, applications, firmware, programs) that make the method of the various embodiments of the present disclosure executable on a machine or a computer, and non-transitory computer-readable media that keeps the software or commands and can be executed on a device or a computer.
Number | Date | Country | Kind |
---|---|---|---|
10-2019-0156132 | Nov 2019 | KR | national |
The present application claims priority to 10-2019-0156132, filed Nov. 28, 2019, the entire contents of which are incorporated herein for all purposes by this reference.