KR20190065091A - Apparatus and method for establishing secure channel in message processing system - Google Patents

Abstract

Provided are a security channel formation apparatus in a message processing system, capable of reinforcing security in message transmission/reception, and a method thereof. According to one embodiment of the present invention, the security channel formation apparatus in a message processing system comprises: one or more processors; a memory; and a channel management unit generating a transport layer security (TLS) channel and a channel client through a TLS protocol, receiving a channel formation request message including an ID allocated to the channel client from the channel client through the TLS channel, verifying the ID, and transmitting a channel formation response message to the channel client through the TLS channel in accordance with a verification result to form a TLS-based security channel.

Description

TECHNICAL FIELD [0001] The present invention relates to an apparatus and a method for forming a secure channel in a message processing system,

Embodiments of the invention relate to message transmission and reception techniques associated with application services.

Recently, with the generalization of mobile terminals and the development of information communication technology, there is an increasing demand for a message processing system that provides various message services. Such a message processing system can be applied to various fields such as a security service, an e-mail service, and a payment service. In the message processing system, the transmitting side and the receiving side send and receive various messages related to a service provided by the message processing system. At this time, the message processing system needs to maintain the continuity of the service and ensure the reliability of the message transmitted between the transmitting side and the receiving side in order to protect the system against external attack.

Korean Patent Publication No. 10-2017-0087116 (July 27, 2017)

Embodiments of the present invention provide an apparatus and method for secure channel formation in a message processing system.

A secure channel forming device in a message processing system, in accordance with an embodiment of the present invention, is configured to create a TLS channel with a channel client through one or more processors, a memory, and a Transport Layer Security (TLS) protocol, Receives a channel formation request message including an ID assigned to the channel client from the channel client, verifies the ID, and transmits a channel establishment response message to the channel client over the TLS channel according to the verification result And a channel management unit for forming a TLS-based secure channel.

The secure channel may be a non-data channel with limited data message transmission.

The channel management unit receives a channel upgrade request message including the ID allocated to the channel client and the ticket information of the channel client from the channel client over the secure channel, And may transmit the channel upgrade response message to the channel client through the secure channel to change the communication channel to a data channel in which the data message is allowed to be transmitted.

The channel formation request message may further include ticket information of the channel client, and the channel management unit may verify the ID and the ticket information.

The secure channel may be a data channel in which data message transmission is allowed.

The ticket information may include a ticket including seed information encrypted using a ticket key, and a ticket key index for the ticket key.

Wherein the channel management unit extracts a ticket key corresponding to a ticket key index included in the ticket information in a ticket key table including a plurality of ticket keys and a plurality of ticket key indexes corresponding to the plurality of ticket keys, The ticket is decrypted using the extracted ticket key, and the ticket can be verified by using the seed information included in the decrypted ticket.

The seed information includes a ticket valid period, and the channel management unit can verify the ticket according to whether or not the ticket valid period has elapsed.

Wherein the seed information includes an ID of a channel client that has issued the ticket and the channel management unit verifies the ticket according to whether the ID included in the channel formation request message matches an ID included in the seed information, can do.

If the verification is successful, the channel management unit may transmit a channel establishment response message including the initial sequence number to the channel client.

Wherein the channel management unit checks a sequence number of a packet received from the channel client over the secure channel after forming the secure channel and if the sequence number is the same as the sequence number of a previously received packet, You can block channels.

The channel client may be a device management module.

The channel client may be a service management module.

A secure channel forming method in a message processing system according to an embodiment of the present invention includes: generating a TLS channel with a channel client through a Transport Layer Security (TLS) protocol; Receiving a channel establishment request message including an ID allocated to the channel client, verifying the ID, and transmitting a channel establishment response message to the channel client over the TLS channel according to the verification result, And forming a secure channel.

The secure channel may be a non-data channel with limited data message transmission.

Receiving a channel upgrade request message including an ID allocated to the channel client and ticket information of the channel client from the channel client over the secure channel, verifying the ID and the ticket information included in the channel upgrade request message, Transmitting the channel upgrade response message to the channel client through the secure channel and changing the communication channel to a data channel in which the data message transmission is permitted.

The channel formation request message further includes ticket information of the channel client, and the verifying step may verify the ID and the ticket information.

The secure channel may be a data channel in which data message transmission is allowed.

The ticket information may include a ticket including seed information encrypted using a ticket key, and a ticket key index for the ticket key.

Wherein the step of verifying the identity and the ticket information comprises the steps of: receiving a ticket corresponding to a ticket key index included in the ticket information in a ticket key table including a plurality of ticket keys and a plurality of ticket key indexes corresponding to the plurality of ticket keys, Extracting the key, decrypting the ticket using the extracted ticket key, and verifying the ticket using the seed information included in the decrypted ticket.

The seed information includes a ticket validity period, and the step of verifying the ticket may verify the ticket according to whether or not the ticket validity period has elapsed.

Wherein the seed information includes an ID of a channel client that has issued the ticket, and wherein the step of verifying the ticket comprises: determining whether the ID included in the channel formation request message matches an ID included in the seed information, You can verify the ticket.

The forming step may transmit a channel formation response message including the initial sequence number to the channel client when the verification is successful.

Identifying a sequence number of a packet received from the channel client over the secure channel after the forming, blocking the secure channel if the sequence number is equal to a sequence number of a previously received packet, As shown in FIG.

The channel client may be a device management module.

The channel client may be a service management module.

According to embodiments of the present invention, a security channel is established between a message server and a channel client, and a message is transmitted / received between a message server and a channel client through a formed secure channel, thereby enhancing the security of message transmission / reception.

1 is a block diagram illustrating a configuration of a message processing system according to an embodiment of the present invention;
2 is a flowchart illustrating a process of forming a secure channel between a device management module and a device channel management unit according to an embodiment of the present invention.
3 is a flowchart illustrating a process for changing a non-data channel formed between a device management module and a device channel management unit to a data channel according to an embodiment of the present invention.
4 is a flowchart illustrating a process of forming a secure channel between a device management module and a device channel management unit according to another embodiment of the present invention.
5 is a flowchart illustrating a process of forming a secure channel between a service management module and a service channel management unit according to an embodiment of the present invention.
6 is a flowchart illustrating a process of forming a secure channel between a device management module and a registration server according to an embodiment of the present invention.
7 is a flowchart illustrating an application server registration process according to an embodiment of the present invention.
8 is a flowchart illustrating a DMID issuance process according to an embodiment of the present invention.
9 is a flowchart illustrating an application service activation process according to an embodiment of the present invention.
10 is a flowchart illustrating a data message transmission procedure transferred from the device management module to the service management module according to an embodiment of the present invention.
11 is a flowchart illustrating a data message transmission procedure transferred from a service management module to a device management module according to an embodiment of the present invention.
Figure 12 is a block diagram illustrating and illustrating a computing environment including a computing device suitable for use in the exemplary embodiments.

Hereinafter, specific embodiments of the present invention will be described with reference to the drawings. The following detailed description is provided to provide a comprehensive understanding of the methods, apparatus, and / or systems described herein. However, this is merely an example and the present invention is not limited thereto.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings. In the following description, well-known functions or constructions are not described in detail since they would obscure the invention in unnecessary detail. The following terms are defined in consideration of the functions of the present invention, and may be changed according to the intention or custom of the user, the operator, and the like. Therefore, the definition should be based on the contents throughout this specification. The terms used in the detailed description are intended only to describe embodiments of the invention and should in no way be limiting. Unless specifically stated otherwise, the singular form of a term includes plural forms of meaning. In this description, the expressions "comprising" or "comprising" are intended to indicate certain features, numbers, steps, operations, elements, parts or combinations thereof, Should not be construed to preclude the presence or possibility of other features, numbers, steps, operations, elements, portions or combinations thereof.

1 is a block diagram illustrating a configuration of a message processing system according to an embodiment of the present invention.

1, a message processing system 10 according to an embodiment of the present invention includes an application service system 100 and one or more user devices 200-1 and 200-2 and a message server 300 .

The message processing system 10 includes application clients 230-1, 230-2, 230-3 and 230-4 installed in the respective user devices 200-1 and 200-2 and respective application clients 230-1 and 230-2 -2, 230-3, and 230-4 to enable reliable message exchange between application servers 130-1, 130-2, and 130-3 that provide application services.

On the other hand, the application clients 230-1, 230-2, 230-3, and 230-4 and the application servers 130-1, 130-2, and 130-3 are connected to the user devices 200-1 , 200-2 and an application installed in the application service system 100. [

For example, the application 1 clients 230-1 and 230-3 installed in the user device 1 (200-1) and the user device 2 (200-2) are connected to the application 1 server 130 -1). ≪ / RTI > The application 2 client 230-2 installed in the user device 1 200-1 can receive the application service from the application 2 server 130-2 installed in the application service system 100, The application 3 client 230-3 installed in the application server 200-2 can receive the application service from the application 3 server 130-3 installed in the application service system 100. [

On the other hand, the application service may be a security related service such as camera control of the user devices 200-1 and 200-2, microphone control, recording function control, and the like. However, application services are not necessarily limited to security-related services, and application clients 230-1, 230-2, 230-3, and 230-4 and application servers 130-1, 130-2, And may include various types of services performed by the application clients 230-1, 230-2, 230-3, and 230-4 according to data transmitted and received between the application clients 230-1, 230-2, 230-3, and 230-4.

The application servers 130-1, 130-2 and 130-3 and the application clients 230-1, 230-2, 230-3 and 230-4 have application IDs (Application IDs) Hereinafter referred to as " APID "). For example, the application 1 client 230-1, 230-3 and the application 1 server 130-1 may have the same APID (e.g., APID 1) and the application 2 client 230-2 The application 2 server 130-2 may also have the same APID (e.g., APID 2).

Each of the application servers 130-1, 130-2, and 130-3 may have an Application Instance ID (APIID) for identifying each application server in addition to the above-described APID. Specifically, unlike the example shown in FIG. 1, when there are a plurality of application servers providing application services identified by APID 1, the application servers have the same APID (i.e., APID 1) Can be different.

Meanwhile, the APID and the APIID may be previously allocated by the administrator of the message server 300.

The application service system 100 includes one or more application servers 130-1, 130-2, 130-3 and one or more service management modules 110-1, 110-2, 110-3 and a database 150 do.

The application service system 100 may be located in a first network. At this time, the first network may be an intranet of an organization or a corporation providing application services using, for example, each application server 130-1, 130-2, and 130-3.

On the other hand, the application service system 100 may include one or more physical servers. Specifically, each configuration of the application service system 100 may be implemented in one physical server, but is not limited thereto, and may be implemented in a plurality of physical servers according to an embodiment.

The service management modules 110-1, 110-2 and 110-3 transmit and receive various messages between the application servers 230-1, 130-2 and 130-3 and the message server 300, respectively. According to an embodiment of the present invention, each of the service management modules 110-1, 110-2, and 110-3 includes one or more service channel management units 310-1 and 310-2 included in the message server 300 And can transmit and receive messages to and from the service channel management units 310-1 and 310-2 through the formed communication channel. A communication channel formed between each of the service management modules 110-1, 110-2 and 110-3 and each of the service channel management units 310-1 and 310-2 may be a TCP (Transmission Control Protocol) Based Transport Layer Security (TLS) communication channel. Specifically, each of the service management modules 110-1, 110-2, and 110-3 transmits a message including data requested to be transmitted from the corresponding application server 130-1, 130-2, To the formed service channel management units 310-1 and 310-2. Each of the service management modules 110-1, 110-2, and 110-3 transmits the data included in the message received from the service channel management units 310-1 and 310-2 in which the communication channel is formed to the corresponding application server 130-1, 130-2, and 130-3.

Each of the service management modules 110-1, 110-2, and 110-3 may be implemented as one configuration of the corresponding application servers 130-1, 130-2, and 130-3, for example. However, But the present invention is not limited thereto and may be implemented in a configuration different from the corresponding application servers 130-1, 130-2, and 130-3 according to the embodiment.

For example, the service management module 1 (110-1) and the service management module 2 (110-2) can be implemented as a single configuration of the application 1 server 130-1 and the application 2 server 130-2 . In this case, each of the service management modules 110-1 and 110-2 may be provided with a corresponding application server 130-1 (for example, in the form of an application programming interface (API) function call using a library and a callback function call , 130-2, and 130-3.

As another example, the service management module 3 (110-3) may be implemented in a configuration separate from the application 3 server 130-3. In this case, the service management module 3 (110-3) can communicate in one direction via HTTP (HyperText Transfer Protocol), for example.

According to an embodiment of the present invention, the service management modules 110-1, 110-2, and 1103 may include a service management group ID (SMGID) and a service management module instance ID, hereinafter referred to as " SMIID "). In this case, when there are a plurality of application servers providing the same application service, the SMGID is an ID assigned to a service management group including service management modules that perform message transmission / reception for each of the application servers, It can be the ID assigned to the module.

For example, assuming that the application 1 server 130-1 and the application 2 server 130-2 provide the same application service, the service management module 1 110-1 and the service management module 2 110-2 ) Have the same SMGID, but the SMIID is different. Assuming that the application 3 server 130-3 provides application services different from the application 1 server 130-1 and the application 2 server 130-2, the SMGID of the service management module 3 (110-3) And the SMIID are different from the SMGID and SMIID of the service management module 1 (110-1) and the service management module 2 (110-2).

Meanwhile, the SMGID and the SMIID of the service management module 110 can be previously allocated by the administrator of the message server 300 like the APID and APIID.

The database 150 is a storage for storing various kinds of information required for sending and receiving messages between the service management modules 110-1, 110-2, and 110-3 and the service channel management units 310-1 and 310-2.

In the example shown in FIG. 1, the application service system 100 includes only one database 150, but the present invention is not limited thereto, and may include a plurality of databases according to an embodiment .

Each of the user devices 200-1 and 200-2 includes one or more device management modules 210-1, 210-2, and 210-3, one or more application clients 230-1, 230-2, 230-3, -4) and databases 250-1 and 250-2.

Each of the user devices 200-1 and 200-2 may be a mobile terminal, such as a smart phone, a notebook, a tablet PC, or the like, and may be located in a second network. At this time, the second network may be an outside area of the first network, for example, the internet.

The device management modules 210-2, 210-2 and 210-3 transmit and receive various messages between the application clients 230-1, 230-2, 230-3 and 230-4 and the message server 300, respectively . Each of the device management modules 210-2, 210-2 and 210-3 includes one or more device channel management units 330-1 and 330-2 included in the message server 300, And can transmit and receive messages to and from the device channel management units 330-1 and 330-2 in which the communication channels are formed. At this time, a communication channel formed between each of the device management modules 210-1, 210-2 and 210-3 and each of the device channel management units 330-1 and 330-2 may be, for example, a TCP-based TLS communication channel Lt; / RTI > Specifically, each of the device management modules 210-2, 210-2, and 210-3 includes data requested to be transmitted from the corresponding application clients 230-1, 230-2, 230-3, and 230-4 Message to the device channel management units 330-1 and 330-2 in which the communication channel is formed. In addition, the device management modules 210-2, 210-2 and 210-3 transmit the data included in the message received from the device channel management units 330-1 and 330-2 having the communication channels to the corresponding application clients 230 -1, 230-2, 230-3, and 230-4.

Each of the user devices 300-1 and 300-2 may include one or more device management modules 210-1, 210-2, and 210-3, and each of the device management modules 210-1 and 210- 2, and 210-3 can perform bidirectional communication with one or more application clients 230-1, 230-2, 230-3, and 230-4. At this time, the device management modules 210-1, 210-2, and 210-3 may include one or more application clients 230-1, 230-2, and 230-3 in the form of API function calls and callback function calls using, for example, -3, and 230-4, respectively. For example, in the case of the user device 1 (200-1), the device management module 1 (210-1) and the application 2 client (230-2) performing bidirectional communication with the application 1 client And a device management module 2 (210-2) for performing the device management. And a device management module 3 210-3 that performs bidirectional communication with the application 1 client 230-3 and the application 3 client 200-4 in the case of the user device 2 200-2.

According to an embodiment of the present invention, each of the device management modules 210-2, 210-2 and 210-3 may have a different Device Management ID (DMID) The DMIDs of the mobile stations 210-2, 210-2, and 210-3 can be allocated by the registration server 350 as will be described later.

The databases 250-1 and 250-2 store various information necessary for transmitting and receiving messages between the device management modules 210-1, 210-2 and 210-3 and the device channel management units 130-1 and 130-2 It is a repository for storing.

The message server 300 is connected to the channel clients included in the application service system 100, that is, the service management modules 110-1, 110-2, and 110-3 and the user devices 200-1 and 200-2 And relay the message between the included channel clients, i.e., the device management module 210-1, 210-2, and 210-3.

The message server 300 may include one or more servers and may be located in a third network between the first network and the second network. At this time, the third network is a sub network located between the first network and the second network, and a firewall may exist between the first network and the third network.

The message server 300 includes a channel manager including one or more service channel management units 310-1 and 310-2 and one or more device channel management units 330-1 and 330-2, Lt; RTI ID = 0.0 > 370 < / RTI >

The service channel management units 310-1 and 310-2 form a communication channel with one or more service management modules 110-1, 110-2, and 110-3, and the service management modules 110-1, 110-2, 110-3 can relay messages exchanged between the service management modules 110-1, 110-2, 110-3 and the device management modules 210-1, 210-2, 210-3. At this time, the communication channel formed between the service channel management units 310-1 and 310-2 and the service management modules 110-1, 110-2 and 110-3 may be, for example, a TCP-based TLS communication channel have.

The device channel management units 330-1 and 330-2 form communication channels with one or more device management modules 210-1, 210-2 and 210-3, and the device management modules 210-1, 210-2, 210-3 can relay messages exchanged between the device management modules 210-1, 210-2, and 210-3 and the service management modules 110-1, 110-2, and 110-3. At this time, the communication channel formed between the device channel management units 330-1 and 330-2 and the device management modules 210-1, 210-2 and 210-3 may be, for example, a TCP-based TLS communication channel have.

The service channel management units 310-1 and 310-2 and the device channel management units 330-1 and 330-2 may use the routing table stored in the database 370, And can route messages received from the service management modules 110-1, 110-2, and 110-3 or the device management modules 210-1, 210-2, and 210-3.

At this time, for example, the routing table may include the ID (i.e., at least one of SMGID and SMIID) of each of the service management modules 110-1, 110-2, and 110-3 and each of the service management modules 110-1, (I.e., at least one of the APID and the APIID) of the application servers 130-1, 130-2, and 130-3 corresponding to the first, second, and third application servers 130-1, 130-2, and 130-3.

In addition, the routing table may include, for example, connection information (e.g., ID of the service channel management unit, IP address, port number, etc.) of each service channel management unit 310-1 and 310-2 and each service channel management unit 310 -1, 310-2) of the service management modules 110-1, 110-2, 110-3 (that is, at least one of the SMGID and SMIID) connected through the communication channel is mapped to the second routing table .

The routing table may include, for example, connection information (e.g., ID, IP address, port number, etc.) of each of the device channel management units 330-1 and 330-2 and each device channel management unit 330 -1, and 330-2 to the DMIDs of the device management modules 210-1, 210-2, and 210-3 connected through the communication channel.

The first routing table and the second routing table may be managed by the respective service channel management units 310-1 and 310-2 and the third routing table may be managed by the device channel management units 330-1 and 330-2, Lt; / RTI >

Specifically, the first routing table can be updated by each of the service channel management units 310-1 and 310-2 in the process of registering application servers 130-1, 130-2, and 130-3, which will be described later. In the second routing table, a communication channel is established between each of the service channel management units 310-1 and 310-2 and each of the service management modules 110-1, 110-2, and 110-3, And may be updated by the respective service channel management units 310-1 and 310-2 when the channel is terminated. In the third routing table, a communication channel is formed between each of the device channel management units 330-1 and 330-2 and each of the device management modules 210-1, 210-2, and 210-3, And may be updated by the device channel management units 330-1 and 330-2 when the channel is terminated.

The registration server 350 manages device information (e.g., IP address, MAC address, and telephone number) for each of the user devices 200-1 and 200-2, a device management module 210-1 210-2 and 210-3 and allocation of the device channel management units 330-1 and 330-2 to be connected to the respective device management modules 210-1, 210-2 and 210-3 do.

The database 370 is a storage for storing various information including the above-described routing table.

Hereinafter, the operation among the components in the message processing system 10 will be described in detail with reference to FIGS. 2 to 11. FIG. 2 to 11 and the following description, the application server 130 may be one of the application servers 130-1, 130-2, and 130-3, and the service management module 110 may be provided for each application server 130-1, 130-2, and 130-3. The service management modules 110-1, 110-2, and 110-3 may be any of the service management modules 110-1, 110-2, and 110-3. The service channel management unit 310 may be one of service channel management units 310-1 and 310-2 included in the message server 300. The device channel management unit 330 may include a service channel management unit And may be one of the device channel management units 310-1 and 310-2. The application client 230 may also be one of the application clients 230-1, 230-2, 230-3, and 230-4 included in one of the user devices 200-1 and 200-2, The management module 210 is a device management module 210-1, 210-2, or 210-3 that performs message transmission / reception with respect to each of the application clients 230-1, 230-2, 230-3, and 230-4 It can be one. Also, the database 250 may be databases 250-1 and 250-2 included in one of the user devices 200-1 and 200-2.

Form a secure channel between the device management module and the device channel manager

2 is a flowchart illustrating a process of forming a secure channel between a device management module and a device channel management unit according to an embodiment of the present invention.

Referring to FIG. 2, the device management module 210 creates a TLS channel with the device channel management unit 330 through the TLS protocol (S210). At this time, the TLS channel may be generated using, for example, a known TLS handshake protocol.

Thereafter, the device management module 210 transmits a channel formation request message to the device channel management unit 330 through the generated TLS channel (S220). Specifically, the device management module 210 may transmit an encrypted channel formation request message to the device channel management unit 330 using the session key of the TLS channel. Meanwhile, the channel formation request message may include the DMID of the device management module 210.

Thereafter, the device channel management unit 330 verifies the DMID included in the channel formation request message (S230). Specifically, the device channel management unit 330 may decode the received channel formation request message using the session key of the TLS channel, and then verify the DMID included in the decoded channel formation request message. At this time, if the DMID included in the channel forming request message is not a DMID issued by the registration server 350 through a DMID issuing process to be described later, or is a DMID whose connection is blocked , It can be determined that the DMID verification has failed. If the DMID verification is successful, the device channel management unit 330 notifies the device channel management unit 330 of the connection information (for example, ID, IP address, port number, etc. of the device channel management unit 330) And add it to the third routing table stored in the database 370.

Then, the device channel management unit 330 transmits a channel establishment response message to the device management module 210 through the TLS channel to form a TLS-based secure channel (S240). Specifically, the device channel management unit 330 may transmit the encrypted channel formation response message to the device management module 210 using the session key of the TLS channel.

Meanwhile, the TLS-based secure channel means a communication channel for transmitting and receiving an encrypted message using a session key of a TLS channel, for example, by using TCP.

Meanwhile, the channel formation response message may be a channel formation success message or a channel formation failure message. In detail, when the DMID verification is successful, the device channel management unit 330 may transmit a channel formation success message including the initial sequence number to the device management module 210. At this time, the initial sequence number can be randomly generated by the device channel management unit 130 when the DMID verification is successful. On the other hand, if the DMID verification fails, the device channel management unit 330 may transmit a channel formation failure message to the device management module 210. [

Meanwhile, when the secure channel is successfully formed, the device management module 210 may include the sequence number in the packet transmitted through the secure channel. At this time, the sequence number included in each packet may be increased by a predetermined amount every time the packet is transmitted starting from the initial sequence number. The device channel management unit 330 may check the sequence number included in the packet received through the secure channel and may block the secure channel formed with the device management module 210 if the sequence number is the same as the sequence number of the previously received packet .

2 may be performed when there is no ticket issued to the device management module 210. The secure channel generated through the process shown in FIG. 2 may include non-data (Non-Data) channel. At this time, the data message may mean a message including data requested to be transmitted by the application client 230 or the application server 130 for the application service. That is, the device channel management unit 330 can block the secure channel if the message received from the device management module 110 through the secure channel formed through the process shown in FIG. 2 is a data message.

3 is a flowchart illustrating a process for changing a non-data channel formed between a device management module and a device channel management unit to a data channel according to an embodiment of the present invention.

The process shown in FIG. 3 can be performed, for example, in a state where a non-data channel is formed according to the procedure shown in FIG. In addition, the data channel may mean a secure channel in which transmission of a data message is allowed.

3, the device management module 210 transmits a channel upgrade request message to the device channel management unit 330 through the non-data channel formed with the device channel management unit 330 (S310). At this time, the channel upgrade request message may include DMID and ticket information of the device management module 210.

In addition, the ticket information may include a ticket and a ticket key index. Details of generating and issuing ticket information of the device management module 210 will be described later.

Then, the device channel management unit 330 verifies the DMID and the ticket information included in the channel upgrade request message (S320).

For example, when the DMID included in the channel upgrade request message is not the DMID issued by the registration server 350 through the DMID issuing process, which will be described later, It can be judged that the verification has failed.

On the other hand, the device channel management unit 330 can check the ticket key index in the ticket information and extract the ticket key mapped to the corresponding ticket key index in the ticket key table stored in the database 370. At this time, the ticket key table may include a plurality of ticket keys and a plurality of ticket key indexes mapped to each of the plurality of ticket keys.

On the other hand, when the ticket key table does not have a ticket key index matching the ticket key index included in the ticket information, the device channel management unit 330 can determine that the ticket information is invalid.

On the other hand, when the ticket key is extracted from the ticket key table, the device channel management unit 330 can decode the ticket included in the ticket information using the extracted ticket key. At this time, if the decryption of the ticket fails, the device channel management unit 330 can determine that the ticket information is invalid.

On the other hand, when the ticket decryption is successful, the device channel management unit 330 can verify the validity of the ticket by using the DMID included in the seed information and the channel upgrade request message included in the decrypted ticket. Specifically, as described later, the seed information may include the DMID and the ticket validity period, and the device channel management unit 330 may determine that the DMID included in the seed information does not match the DMID included in the channel upgrade request message, If the included ticket validity period has elapsed, it can be determined that the ticket is invalid.

Thereafter, the device channel management unit 330 may transmit the channel upgrade response message to the device management module 210 through the non-data channel according to the DMID and the result of the ticket information verification to change the non-data channel to the data channel (S330) .

Specifically, the device channel management unit 330 may transmit a channel upgrade success message to the device management module 210 when the DMID and the ticket information are successfully verified. On the other hand, if the verification of at least one of the DMID and the ticket information fails, the device channel management unit 330 may transmit a channel upgrade failure message to the device management module 210. [

4 is a flowchart illustrating a process of forming a secure channel between a device management module and a device channel management unit according to another embodiment of the present invention.

Referring to FIG. 4, the device management module 210 generates a TLS channel with the device channel management unit 330 through the TLS protocol (S410). At this time, the TLS channel may be generated using, for example, a known TLS handshake protocol.

Then, the device management module 210 transmits a channel formation request message to the device channel management unit 330 through the generated TLS channel (S420). Specifically, the device management module 210 may transmit an encrypted channel formation request message to the device channel management unit 330 using the session key of the TLS channel. In addition, the channel formation request message may include the DMID and the ticket information of the device management module 210.

Then, the device channel management unit 330 verifies the DMID and the ticket information included in the channel formation request message (S430).

For example, when the DMID included in the channel forming request message is not a DMID issued by the registration server 350 through a DMID issuing process to be described later, or is a DMID whose connection is blocked, It can be judged that the verification has failed.

The device channel management unit 330 may check the ticket key index in the ticket information and extract the ticket key mapped to the corresponding ticket key index in the ticket key table stored in the database 370. [ At this time, if there is no ticket key index matching the ticket key index included in the ticket information in the ticket key table, the device channel management unit 330 can determine that the ticket is invalid.

On the other hand, when the ticket key is extracted from the ticket key table, the device channel management unit 330 can decode the ticket included in the ticket information using the extracted ticket key. At this time, if the decryption of the ticket fails, the device channel management unit 330 can determine that the ticket information is invalid.

On the other hand, when the ticket decryption is successful, the device channel management unit 330 can verify the validity of the ticket by using the DMID included in the seed information and the channel formation request message included in the decrypted ticket. Specifically, if the DMID included in the seed information does not match the DMID included in the channel formation request message, or if the ticket valid period included in the seed information has elapsed, the device channel management unit 330 determines that the ticket is invalid can do.

Then, the device channel management unit 330 transmits a channel establishment response message to the device management module 210 through the TLS channel to form a TLS-based secure channel (S440). Specifically, the device channel management unit 330 may transmit the encrypted channel formation response message to the device management module 210 using the session key of the TLS channel.

Meanwhile, the channel formation response message may be a channel formation success message or a channel formation failure message. Specifically, when the verification of the DMID and the ticket information is successful, the device channel management unit 330 may transmit a channel formation success message including the initial sequence number to the device management module 210. [ At this time, the initial sequence number can be randomly generated by the device channel management unit 330 when the DMID and the ticket information are successfully verified. On the other hand, if the verification of at least one of the DMID and the ticket information fails, the device channel management unit 330 may transmit a channel formation failure message to the device management module 210.

Meanwhile, when the secure channel is successfully formed, the device management module 210 may include the sequence number in the packet transmitted through the secure channel. At this time, the sequence number included in each packet may be increased by a predetermined amount every time the packet is transmitted starting from the initial sequence number. The device channel management unit 330 may check the sequence number included in the received packet and block the secure channel formed with the device management module 210 if the sequence number is the same as the sequence number of the previously received packet.

4 may be performed when a ticket issued to the device management module 210 exists, and the secure channel generated through the process shown in FIG. 4 may include a data channel May be

Establishing a secure channel between the service management module and the service channel manager

5 is a flowchart illustrating a process of forming a secure channel between a service management module and a service channel management unit according to an embodiment of the present invention.

Referring to FIG. 5, the service management module 110 creates a TLS channel with the service channel management unit 310 through the TLS protocol (S510).

Thereafter, the service management module 110 transmits a channel establishment request message to the service channel management unit 310 through the generated TLS channel (S520). Specifically, the service management module 110 may transmit the encrypted channel formation request message to the service channel management unit 310 using the session key of the TLS channel.

Meanwhile, the channel formation request message may include the ID (i.e., at least one of SMGID and SMIID) of the service management module 110 and ticket information. At this time, the ticket information may include a ticket and a ticket key index.

Meanwhile, the ticket information of the service management module 110 may be previously issued by the administrator of the message server 300, for example. Specifically, the ticket included in the ticket information of the service management module 110 may be generated by encrypting the seed information with the ticket key selected in the ticket key table stored in the database 370 of the message server 300. The seed information includes at least one of the ID of the service management module 110 (at least one of SMGID and SMIID), the device information of the server including the service management module 100 (for example, MAC address, IP address, etc.) and ticket validity period. The ticket key index included in the ticket information may be a ticket key index mapped to a ticket key selected for encryption of seed information in the ticket key table.

Thereafter, the service channel management unit 310 verifies the ID and the ticket information included in the channel formation request message (S530).

For example, if the ID included in the channel forming request message is not the ID issued by the administrator of the message server 300, or if the connection is blocked, the service channel managing unit 310 determines that the ID verification has failed can do.

Meanwhile, the service channel management unit 310 may check the ticket key index included in the ticket information and extract the ticket key mapped to the corresponding ticket key index in the ticket key table stored in the database 370. [ At this time, if the ticket key table does not have a ticket key index matching the ticket key index included in the ticket information, the service channel management unit 310 can determine that the ticket information is invalid.

On the other hand, when the ticket key is extracted from the ticket key table, the service channel management unit 310 can decrypt the ticket included in the ticket information using the extracted ticket key. At this time, if the decryption of the ticket fails, the service channel management unit 310 can determine that the ticket information is invalid.

On the other hand, when the ticket decryption is successful, the service channel management unit 310 can verify the validity of the ticket using the seed included in the decrypted ticket and the ID included in the channel formation request message. Specifically, if the ID included in the seed information does not match the ID of the service management module 110 included in the channel formation request message, or if the ticket valid period included in the seed information has elapsed, the service channel management unit 310 It can be determined that the ticket is not valid.

Then, the service channel management unit 310 transmits a channel establishment response message to the service management module 110 through the TLS channel to form a TLS-based secure channel (S540). Specifically, the service channel management unit 310 may transmit an encrypted channel establishment response message to the service management module 110 using the session key of the TLS channel.

Meanwhile, the channel formation response message may be a channel formation success message or a channel formation failure message. Specifically, when the verification of the ID and the ticket information is successful, the service channel management unit 310 may transmit a channel formation success message including the initial sequence number to the service management module 110. At this time, the initial sequence number can be randomly generated by the service channel management unit 310 when the verification of the ID and the ticket information is successful. On the other hand, if the verification of at least one of the ID and the ticket information fails, the service channel management unit 310 may transmit a channel formation failure message to the service management module 110.

Meanwhile, when the secure channel is successfully formed, the service management module 110 may include the sequence number in the packet transmitted through the secure channel. At this time, the sequence number included in each packet may be increased by a predetermined amount every time the packet is transmitted starting from the initial sequence number. In addition, the service channel manager 310 may check the sequence number included in the received packet and block the secure channel formed with the service management module 110 if the sequence number is the same as the sequence number of the previously received packet.

5 may be performed when there is a ticket issued to the service management module 110. The secure channel generated through the process shown in FIG. 5 may be a data channel May be

Establish a secure channel between the device management module and the registration server

6 is a flowchart illustrating a process of forming a secure channel between a device management module and a registration server according to an embodiment of the present invention.

Referring to FIG. 6, the device management module 210 creates a TLS channel with the registration server 350 through the TLS protocol (S610). At this time, the TLS channel may be generated using, for example, a known TLS handshake protocol.

Thereafter, the device management module 210 transmits a channel establishment request message to the registration server 350 through the generated TLS channel (S620). Specifically, the device management module 210 may transmit the encrypted channel formation request message to the registration server 350 using the session key of the TLS channel. Meanwhile, the channel formation request message may include the DMID of the device management module 210.

Thereafter, the registration server 350 verifies the DMID included in the channel establishment request message (S630). Specifically, the registration server 350 may decrypt the received channel formation request message using the session key of the TLS channel, and then verify the DMID included in the decoded channel formation request message. At this time, if the received DMID is not the DMID issued by the registration server 350 through the DMID issuing process, which will be described later, or the DMID whose connection is blocked, the registration server 350 judges that the DMID verification has failed It can be judged.

Thereafter, the registration server 350 transmits a channel establishment response message to the device management module 210 through the TLS channel to form a TLS-based secure channel (S640). Specifically, the registration server 350 may transmit the encrypted channel establishment response message to the device channel management unit 330 using the session key of the TLS channel.

Meanwhile, the channel formation response message may be a channel formation success message or a channel formation failure message. Specifically, when the DMID verification is successful, the registration server 350 may transmit a channel formation success message including the initial sequence number to the device management module 210. [ At this time, the initial sequence number can be randomly generated by the registration server 350 when the DMID verification is successful. On the other hand, if the DMID verification fails, the registration server 350 can transmit a channel formation failure message to the device management module 210.

Meanwhile, when the secure channel is successfully formed, the device management module 210 may include the sequence number in the packet transmitted through the secure channel. At this time, the sequence number included in each packet may be increased by a predetermined amount every time the packet is transmitted starting from the initial sequence number. Also, the registration server 350 may check the sequence number included in the received packet and block the secure channel formed with the device management module 210 if the sequence number is the same as the sequence number of the previously received packet.

Meanwhile, the secure channel generated through the process shown in FIG. 6 may be a non-data channel with limited data message transmission.

Application server registration

7 is a flowchart illustrating an application server registration process according to an embodiment of the present invention.

Referring to FIG. 7, the service management module 110 forms a secure channel with the service channel management unit 310 (S710). At this time, the secure channel can be generated through the procedure shown in Fig. 5, for example.

Thereafter, the service management module 110 receives a registration request from the application server 130 (S720). At this time, the registration request received from the application server 130 may include the ID of the application server 130 (i.e., at least one of APID and APIID).

Thereafter, the service management module 110 transmits an application server registration message to the service channel management unit 310 via the secure channel (S730). At this time, the application server registration message may include the ID (i.e., at least one of SMGID and SMIID) of the service management module 110 and the ID (i.e., at least one of APID and APIID) of the application server 130.

Thereafter, the service channel management unit 310 transmits an application server registration response message to the service management module 110 (S740). Specifically, the service channel management unit 310 verifies the ID of the service management module 110 and the ID of the application server 130 included in the application server registration request message, and, based on the verification result, A registration failure message can be transmitted.

For example, the service channel manager 310 determines whether the ID of the service management module 110 included in the application server registration request message (at least one of SMGID and SMIID) or the ID of the application server 130 is an ID Or an ID issued by the administrator of the message server 300. [0064]

If the verification is successful, the service channel management unit 310 maps the ID of the service management module 110 included in the application server registration request message and the ID of the application server to the first routing table stored in the database 370 Can be added.

Thereafter, the service management module 110 transmits the registration result of the application server 130 to the application server 130 (S750).

DMID issue

8 is a flowchart illustrating a DMID issuance process according to an embodiment of the present invention.

Referring to FIG. 8, first, the device management module 210 receives an application service activation request from the application client 230 (S810).

Thereafter, if there is no DMID issued to the device management module 210, the device management module 210 forms a TLS channel with the registration server 350 through the TLS protocol (S820). At this time, the TLS channel may be generated using, for example, a known TLS handshake protocol.

Thereafter, the device management module 210 transmits a DMID request message including seed information for DMID generation to the registration server 350 through the generated TLS channel (S830). Specifically, the device management module 210 may transmit the encrypted DMID request message to the registration server 350 using the session key of the TLS channel.

The seed information may include, for example, the device information (e.g., MAC address, telephone number, etc.) of the user device 200 including the device management module 210 and the APID of the application client 230 have.

The registration server 350 then generates the DMID for the device management module 310 based on the seed information received from the device management module 210 and transmits the DMID to the device management module 210, (S840). At this time, the registration server 350 can store the generated DMID and the device information of the user device 200 in the database 370.

Thereafter, the registration server 350 transmits a DMID request response message to the device management module 210 through the generated TLS channel (S850). Specifically, the registration server 350 may transmit the encrypted DMID request response message to the device management module 210 using the session key of the TLS channel.

The DMID request response message includes DMID generated by the registration server 350 and connection information (e.g., IP address, port number, etc.) to the device channel management unit 330 allocated to the device management module 210 .

Thereafter, the device management module 210 decrypts the DMID request response message using the session key of the TLS channel, and transmits the DMID included in the DMID request response message and the access information to the device channel management unit 330 to the database 250 (S860).

Enable Application Services

9 is a flowchart illustrating an application service activation process according to an embodiment of the present invention.

Referring to FIG. 9, the device management module 210 receives an application service activation request from the application client 230 (S901). At this time, the application service activation request may include, for example, the APID of the application client 230 and the user authentication information. At this time, the user authentication information may include, for example, a user ID and a password.

Upon receiving the service activation request, the device management module 210 checks whether the DMID is stored in the database 250. If the DMID is not stored, the device management module 210 can perform the DMID issuance procedure shown in FIG.

On the other hand, if the DMID is stored, the device management module 210 forms a secure channel with the device channel management unit 330 allocated to the device management module 210 (S902). At this time, the secure channel may be a secure channel formed through, for example, the process shown in FIG.

Thereafter, the device management module 210 transmits an SMGID request message to the device channel management unit 330 through the secure channel (S903). At this time, the SMGID request message may include the DMID of the device management module 210 and the APID of the application client 230.

Then, the device channel management unit 330 extracts the SMGID mapped to the APID included in the SMGID request message in the first routing table stored in the database 370, and transmits the SMGID response message including the extracted SMGID to the device management module 210 (S904).

Then, the device management module 210 maps the received SMGID to the APID of the application client 230 and stores it in the database 250 (S905).

Thereafter, the device management module 210 transmits an application client registration request message to the device channel management unit 330 through the secure channel (S906). At this time, the application client registration request message may include routing information, the DMID of the device management module 210, the APID of the application client 230, and a user ID. On the other hand, the routing information may include the source and destination of the application client registration request message. For example, the source included in the routing information may be the DMID of the device management module 210, and the destination may be the SMGID of the service management module 110.

Then, the device channel management unit 330 delivers the received application client registration request message to the service channel management unit 310 (S907). Specifically, the device channel management unit 330 can identify the access information of the service channel management unit 310 mapped to the SMGID included as the destination in the routing information of the client registration request message in the second routing table stored in the database 370 have. In addition, the device channel management unit 330 can transmit an application client registration request message to the service channel management unit 310 using the identified access information.

Thereafter, the service channel management unit 310 transmits an application client registration request message to the service management module 110 through the secure channel formed with the service management module 110 (S908). Specifically, the service channel manager 110 may transmit an application client registration request message to the service management module 110 based on the SMGID included in the routing information of the application client registration request message. Meanwhile, the secure channel formed with the service management module 110 may be a secure channel formed through, for example, the process shown in FIG.

Then, the service management module 110 maps the DMID and the user ID included in the application client registration request message to the user table stored in the database 150 (S909).

Thereafter, the service management module 110 transmits an application client registration response message to the service channel management unit 110 via the secure channel (S910). At this time, the application client registration response message may include the routing information and the application client registration result. On the other hand, the routing information may include the origin and destination of the application client registration response message. For example, the source included in the routing information may be, for example, the SMGID of the service management module 110, and the destination may be the DMID of the device management module 210.

Thereafter, the service channel management unit 310 transmits the received client registration response message to the device channel management unit 330 (S911). Specifically, the service channel management unit 310 can identify the access information of the device channel management unit 330 mapped to the DMID included as the destination in the routing information of the client registration response message in the third routing table stored in the database 370 have. In addition, the service channel management unit 310 can transmit an application client registration response message to the device channel management unit 330 using the identified access information.

Then, the device channel management unit 330 transmits an application client registration response message to the device management module 210 via the secure channel based on the DMID included in the routing information of the application client registration response message (S912).

On the other hand, if the application client registration is successful, the device management module 210 transmits a user authentication request message to the device channel management unit 330 through the secure channel (S913). At this time, the user authentication request message may include routing information, DMID of the device management module 210, APID of the application client 230, and user authentication information. On the other hand, the routing information may include the source and destination of the client registration request message. For example, the source included in the routing information may be the DMID of the device management module 210, and the destination may be the APID of the application client 230. In addition, the user authentication information may include, for example, a user ID and a password.

Then, the device channel management unit 330 delivers the received user authentication request message to the service channel management unit 310 (S914). Specifically, the device channel management unit 330 identifies the SMGID mapped to the APID included as the destination in the routing information of the user authentication request message in the first routing table stored in the database 370, and transmits the identified SMGID to the routing information Can be added. The device channel management unit 330 may identify the access information of the service channel management unit 310 mapped to the SMGID identified in the second routing table stored in the database 370. [ The device channel management unit 330 can then transmit the application client registration request message to the service channel management unit 310 using the access information of the identified service channel management unit 310. [

Thereafter, the service channel management unit 310 transmits a user authentication request message to the service management module 110 through the secure channel (S915). Specifically, the service channel management unit 310 transmits a user authentication request message to the service management module 110 based on the SMGID included in the routing information of the user authentication request message in the first routing table stored in the database 370 .

Thereafter, the service management module 110 transmits the user authentication information included in the user authentication request message to the application server 130 (S916).

Then, the application server 130 performs user authentication using the user authentication information, and requests the service management module 110 to transmit the authentication result (S917). At this time, the application server 130 may transmit the user ID and the APID to the service management module 110 together with the authentication result.

Thereafter, the service management module 110 generates a user authentication response message, and transmits the user authentication response message generated through the secure channel to the service channel management unit 310 (S918). At this time, the user authentication response message may include routing information, a user ID, an APID of the application server 130, a DMID of the device management module 210, and an authentication result. In addition, the routing information may include a source and a destination of the user authentication response message. For example, the source included in the routing information may be the SMGID of the service management module 110, and the destination may be the DMID of the device management module 210. At this time, the service management module 110 may identify the DMID mapped to the user ID received from the application server 130 in the user table stored in the database 170, and set the identified DMID as the destination.

Thereafter, the service channel management unit 310 transmits the received user authentication response message to the device channel management unit 330 (S918). Specifically, the service channel management unit 310 can identify the access information of the device channel management unit 330 mapped to the DMID included as the destination in the routing information of the user authentication response message in the third routing table stored in the database 370 have. In addition, the service channel management unit 310 can transmit an application client registration request message to the device channel management unit 310 using the identified access information.

Then, the device channel management unit 330 transmits a user authentication request response message to the device management module 210 through the secure channel based on the DMID included as the destination in the routing information of the user authentication response message (S920).

The device management module 210 confirms the authentication result included in the user authentication response message. If the user authentication is successful, the device management module 210 issues a ticket issue request to the device channel management unit 330 through the secure channel formed with the device channel management unit 330 Message (S921). At this time, the ticket issuance request message may include information of the user device 300 (for example, IP address, MAC address, telephone number, etc.) and DMID of the device management module 210.

Thereafter, the device channel management unit 330 transmits a device management module registration confirmation request message to the service channel management unit 310 (S922). At this time, the device management module registration confirmation request message may include the DMID of the device management module 210.

Thereafter, the service channel management unit 310 transmits a device management module registration confirmation request message to the service management module 110 through the secure channel formed with the service management module 110 (S923).

After that, the service management module 110 determines whether the DMID included in the received device management module registration confirmation request message is included in the user table stored in the database 150, and then transmits a device management module registration confirmation message To the service channel management unit 310 (S924). At this time, the device management module registration confirmation message may include the DMID and the registration confirmation result of the device management module 210.

Thereafter, the service channel management unit 310 transmits the received device management module registration confirmation message to the device channel management unit 330 (S925).

Then, when the device management module 210 is registered, the device channel management unit 330 generates ticket information for the device management module 210 (S926). At this time, the ticket information may include a ticket and a ticket key index. Specifically, the device channel management unit 330 can select one ticket key from the ticket key table. At this time, the ticket key table may be pre-stored in the database 370, and may include a plurality of ticket keys and a ticket key index mapped to each of the plurality of ticket keys. Thereafter, the device channel management unit 330 can generate the ticket for the device management module 310 by encrypting the seed information with the selected ticket key. At this time, the encryption can be performed using, for example, the AES algorithm, but not necessarily limited thereto, and can be performed using various known symmetric key encryption algorithms in addition to the AES algorithm. The seed information may include, for example, the validity period of the ticket, the user device 300 information received through the ticket issue request message, and the DMID of the device management module 210. Then, the registration server 350 can generate ticket information including the generated ticket and the ticket key index mapped to the ticket key selected for generating the ticket.

Thereafter, the device channel management unit 330 transmits a ticket issue response message including ticket information to the device management module 210 through the secure channel formed with the device management module 210 (S927).

Thereafter, the device management module 210 and the device channel management unit 350 upgrade the secure channel formed between them to the data channel (S928). At this time, the data channel upgrade can be performed, for example, through the procedure shown in FIG.

Data message transfer and security between the device management module and the service management module

10 is a flowchart illustrating a data message transmission procedure transferred from a device management module to a service management module according to an embodiment of the present invention.

Referring to FIG. 10, first, the application client 230 requests data transfer to the device management module 210 (S1001). Specifically, the application client 230 may transmit the APID of the application client 230 and the data to be transmitted to the device management module 210. [

Then, the device management module 210 encrypts the data requested to be transmitted and stores the encrypted data in the database 250 (S1002). Specifically, the device management module 210 may encrypt the data requested to be transmitted using the first cryptographic key, and encrypt the first cryptographic key using the second cryptographic key. The device management module 210 may then store the encrypted data and the encrypted first cryptographic key in the database 250.

At this time, the encryption using the first encryption key and the encryption using the second encryption key can be performed using, for example, the AES algorithm. However, the present invention is not limited to this, and various known symmetric key encryption algorithms . ≪ / RTI >

Meanwhile, the first cryptographic key may be a one-time cryptographic key generated by the device management module 210. Specifically, the device management module 210 may generate a first cryptographic key and encrypt the data requested to be transmitted each time there is a data transmission request from the application client 230. At this time, the generated first cryptographic key may be stored in the memory allocated to the device management module 210. Also, the first cryptographic key may be encrypted using the second cryptographic key and stored in the database 250 and then deleted from the memory.

The second encryption key may be a pre-shared encryption key between the device management module 210 and the service management module 110. The second encryption key may be mapped to the DMID of the device management module 210 and the APID of the application client 230, (Not shown). In this case, the device management module 210 may extract the second encryption key mapped to the DMID of the device management module 210 and the APID of the application server 130 in the database 250, have.

Meanwhile, the device management module 210 and the service management module 110 may transmit the second cryptographic key through a Diffie-Hellman key exchange algorithm or a RSA (Rivest, Sharmir, Adleman) key exchange algorithm, for example You can share.

For example, in the application activation process shown in FIG. 9, the device management module 210 generates a private key and a public key, and includes the generated public key in the application client registration request message to the service management module 110 . In addition, the service management module 110 may generate the private key and the public key, and may include the public key in the application client registration response message to the device management module 210. Then, the device management module 210 generates a second cryptographic key using its own private key and the public key of the service management module 110, and transmits the generated second cryptographic key to the DMID of the device management module 210 May be mapped to the APID of the application client (230) and stored in the database (250). The service management module 110 generates a second cryptographic key using its own private key and the public key of the device management module 210 and transmits the generated second cryptographic key to the DMID of the device management module 210 May be mapped to the APID of the application client (230) and stored in the database (150).

In another example, in the application activation process shown in FIG. 9, the device management module 210 generates a private key and a public key, and transmits the generated public key to the service management module 110 by including the generated public key in an application client registration request message . The service management module 110 generates a second cryptographic key, encrypts the generated second cryptographic key with the public key of the device management module 210, and stores the encrypted second cryptographic key in the application client registration response message to the device management module 210 . Thereafter, the device management module 210 decrypts the second encryption key with its own private key, maps the decrypted second encryption key with the DMID of the device management module 210 and the APID of the application client 230, ). ≪ / RTI >

According to an embodiment of the present invention, the device management module 210 may encrypt the second cryptographic key using the third cryptographic key provided from the device channel management unit 330 and store the second cryptographic key in the database 250. The third encryption key may be generated by the device channel management unit 330 and stored in the database 370 of the message server 300 in the process of issuing the DMID shown in FIG. 330 may provide a third cryptographic key to the device management module 210 at the request of the device management module 210.

Specifically, the device management module 210 requests and receives a third encryption key from the device channel management unit 330, encrypts the second encryption key using the received third encryption key, and transmits the encryption key to the database 250 Can be stored. At this time, the received third encryption key may be stored in the memory allocated to the device management module 210, and the second encryption key may be deleted from the memory after encryption.

If the device management module 210 requests encryption of the first cryptographic key, the device management module 210 requests and receives the third cryptographic key from the device channel management unit 330, 250, and may encrypt the first cryptographic key using the decrypted second cryptographic key. At this time, the received third encryption key may be stored in the memory allocated to the device management module 210, and may be deleted from the memory after the second encryption key stored in the database 250 is decrypted.

Meanwhile, encryption and decryption using the third cryptographic key can be performed using, for example, an AES (Advanced Encryption Standard) algorithm, but the present invention is not limited thereto, and various known symmetric key encryption algorithms . ≪ / RTI >

Meanwhile, according to an embodiment of the present invention, the device management module 310 may generate a checksum value for data requested to be transmitted before encrypting the data requested to be transmitted. At this time, the checksum value may use a hash function such as MD5 (Message-Digest algorithm 5), but various algorithms that can be used for data integrity verification besides MD5 can be used.

Thereafter, the device management module 310 transmits a data message to the device channel management unit 330 through the secure channel formed with the device channel management unit 330 (S1003). At this time, the secure channel may be a data channel formed through the process shown in FIG. 3 or FIG. 4, for example.

Meanwhile, the data message transmitted by the device management module 310 includes routing information, data encrypted with the first cryptographic key, a first cryptographic key encrypted with the second cryptographic key, and an APID . ≪ / RTI > The routing information may also include a source and a destination of the data message. In this case, the source included in the routing information may be, for example, the DMID of the device management module 210, and the destination may be the SMGID of the service management module 110, for example.

Also, according to an embodiment, the data message may further include a checksum value for the data requested to be transmitted.

Thereafter, the device channel management unit 330 delivers the received data message to the service channel management unit 310 (S1004). Specifically, the device channel management unit 330 may identify the access information of the service channel management unit 310 mapped to the SMGID included as the destination in the routing information of the data message in the second routing table stored in the database 370. In addition, the device channel management unit 330 can transmit the data message to the service channel management unit 310 using the identified access information.

Thereafter, the service channel management unit 310 transmits a data message to the service management module 110 through the secure channel formed with the service management module 110 (S1005). At this time, the secure channel may be a data channel formed through the process shown in FIG. 5, for example.

Specifically, the service channel manager 310 may transmit a data message to the service management module 110 based on the SMGID included in the routing information of the data message.

Thereafter, the service management module 110 stores the received data message in the database 150 (S1006).

Thereafter, the service management module 110 decodes the data included in the received data message (S1007). Specifically, the service management module 110 may extract the DMID included in the data message and the second cryptographic key mapped to the APID in the database 150. Thereafter, the service management module 110 decodes the first cryptographic key included in the data message using the extracted second cryptographic key, and decrypts the data included in the data message using the decrypted first cryptographic key have. At this time, the decoding using the first cryptographic key and the decoding using the second cryptographic key can be performed using, for example, the AES algorithm. However, the present invention is not limited thereto, and various known symmetric key encryption algorithms . ≪ / RTI >

According to an embodiment of the present invention, the service management module 110 may encrypt the second cipher key using the fourth cipher key provided from the service channel manager 310, and store the second cipher key in the database 150. The fourth encryption key may be generated by the service channel management unit 310 and stored in the database 370 of the message server 300 in the process of registering the application server 130 shown in FIG. 7, for example. The service channel management unit 310 may provide the fourth encryption key to the service management module 110 at the request of the service management module 110.

Specifically, the service management module 110 requests and receives a fourth cryptographic key from the service channel manager 310, encrypts the second cryptographic key using the received fourth cryptographic key, and transmits the encrypted cryptographic key to the database 150 Can be stored. At this time, the received fourth encryption key may be stored in the memory allocated to the service management module 110, and the second encryption key may be deleted from the memory after encryption.

In addition, when the decryption of the first cryptographic key included in the data message is requested, the service management module 110 requests and receives the fourth cryptographic key from the service channel manager 310, and then transmits the received fourth cryptographic key The second cryptographic key stored in the database 150 can be decrypted using the decrypted second cryptographic key, and the first cryptographic key included in the data message can be decrypted using the decrypted second cryptographic key. At this time, the received fourth encryption key may be stored in the memory allocated to the service management module 110, and may be deleted from the memory after the second encryption key stored in the database 150 is decrypted.

Meanwhile, the encryption and decryption using the fourth encryption key can be performed using, for example, the AES algorithm, but the present invention is not limited thereto and can be performed using various known symmetric key encryption algorithms in addition to the AES algorithm .

If the received data message includes a checksum value, the service management module 110 calculates a checksum value from the decoded data and compares the checksum value with a checksum value included in the data message The integrity of the data can be verified.

Thereafter, the service management module 210 transmits an acknowledgment message to the service channel management unit 310 through the secure channel (S1008). At this time, the acknowledgment message may include the routing information and the data reception result. At this time, the routing information can be generated by switching the source and destination included in the routing information of the received data message.

On the other hand, if the data decryption is successful, or both the data decryption and the data integrity verification are successful according to the embodiment, the data reception result may include a code indicating that the data reception is successful. On the other hand, if data decryption fails or data integrity verification fails, the data reception result may include a code indicating that data reception has failed.

On the other hand, if the data decryption is successful, the service management module 110 delivers the decrypted data to the application server 130 (S1009). If the data message includes a checksum value, the service management module 110 may transmit the decrypted data to the application server 130 when both the data decryption and the data integrity verification are successful .

Meanwhile, the service management module 110 deletes the data message stored in the database 150 after transmitting the acknowledgment message to the service channel manager 310 (S1010).

Meanwhile, the service channel management unit 310 transmits an acknowledgment message to the device channel management unit 330 (S1011). Specifically, the service channel management unit 310 can identify the access information of the device channel management unit 330 mapped to the DMID included as the destination in the routing information of the acknowledgment message in the third routing table stored in the database 370 . Thereafter, the service channel management unit 310 can transmit an acknowledgment message to the device channel management unit 330 using the identified access information.

Then, the device channel management unit 330 transmits an acknowledgment message to the device management module 210 through the secure channel based on the DMID included as the destination in the routing information of the acknowledgment message (S1012).

Thereafter, the device management module 210 confirms the data reception result included in the reception confirmation message, and deletes the encrypted data and the encrypted first encryption key stored in the database 1014 when the data processing is successful (S1013 ). On the other hand, if the data processing has failed or the acknowledgment message is not received within the predetermined period, the device management module 210 can re-execute the process after step S1003.

11 is a flowchart illustrating a data message transmission procedure transferred from a service management module to a device management module according to an embodiment of the present invention.

Referring to FIG. 11, the application server 130 requests data transfer to the service management module 110 (S1101). Specifically, the application server 130 may transmit the APID of the application server 130, the user ID, and the data to be transmitted to the service management module 110.

Then, the service management module 110 encrypts the data requested to be transmitted and stores it in the database 150 (S1102).

Specifically, the service management module 110 may encrypt the data requested to be transmitted using the fifth cipher key, and encrypt the fifth cipher key using the second cipher key. The service management module 110 may then store the encrypted data and the encrypted fifth cryptographic key in the database 150. At this time, the encryption using the fifth cryptographic key and the encryption using the second cryptographic key can be performed using, for example, the AES algorithm. However, the present invention is not limited thereto, and various known symmetric key encryption algorithms . ≪ / RTI >

Meanwhile, the fifth cipher key may be a one-time cipher key generated by the service management module 110. Specifically, the service management module 110 may generate a fifth cryptographic key and encrypt the data requested to be transmitted each time there is a data transmission request from the application server 130. At this time, the generated fifth cipher key may be stored in the memory allocated to the service management module 110. [ Further, the fifth cipher key may be deleted from the memory after it is encrypted using the second cipher key and stored in the database 150. [

The second encryption key may be a pre-shared encryption key between the device management module 210 and the service management module 110. The second encryption key may be mapped to the APID of the application client 230 and the DMID of the device management module 210, (150). ≪ / RTI > In this case, the service management module 110 may extract the DMID mapped to the user ID received from the application server 130 in the user table stored in the database 150. [ Also, the service management module 110 may extract the extracted DMID and the second cryptographic key mapped to the APID of the application server 130 from the database 150, and then use it to encrypt the fifth cryptographic key.

Specifically, the device management module 210 and the service management module 110 may be configured to provide a second password (e.g., a password) corresponding to the application client 230 via a Diffie-Hellman key exchange algorithm or a RAS key exchange algorithm, for example. You can share the key.

For example, in the application activation process shown in FIG. 9, the device management module 210 generates a private key and a public key, and includes the generated public key in the application client registration request message to the service management module 110 . In addition, the service management module 110 may generate the private key and the public key, and may include the public key in the application client registration response message to the device management module 210. Then, the device management module 210 generates a second cryptographic key using its own private key and the public key of the service management module 110, and transmits the generated second cryptographic key to the DMID of the device management module 210 May be mapped to the APID of the application client (230) and stored in the database (250). The service management module 110 generates a second cryptographic key using its own private key and the public key of the device management module 210 and transmits the generated second cryptographic key to the DMID of the device management module 210 May be mapped to the APID of the application client (230) and stored in the database (150).

In another example, in the application activation process shown in FIG. 9, the device management module 210 generates a private key and a public key, and transmits the generated public key to the service management module 110 by including the generated public key in an application client registration request message . The service management module 110 generates a second cryptographic key, encrypts the generated second cryptographic key with the public key of the device management module 210, and stores the encrypted second cryptographic key in the application client registration response message to the device management module 210 . Thereafter, the device management module 210 decrypts the second encryption key with its own private key, maps the decrypted second encryption key with the DMID of the device management module 210 and the APID of the application client 230, ). ≪ / RTI >

Meanwhile, according to an embodiment of the present invention, the service management module 110 may encrypt the second cryptographic key using the fourth cryptographic key provided from the service channel management unit 310, and store the second cryptographic key in the database 250. The fourth encryption key may be generated by the service channel management unit 310 and stored in the database 370 of the message server 300 in the process of registering the application server 130 shown in FIG. 7, for example. The service channel management unit 310 may provide the fourth encryption key to the service management module 110 at the request of the service management module 110.

Specifically, the service management module 110 requests and receives a fourth cryptographic key from the service channel manager 310, encrypts the second cryptographic key using the received fourth cryptographic key, and transmits the encrypted cryptographic key to the database 150 Can be stored. At this time, the received fourth encryption key may be stored in the memory allocated to the service management module 110, and the second encryption key may be deleted from the memory after encryption.

If encryption of the fifth cipher key is requested, the service management module 110 requests and receives a fourth cipher key from the service channel manager 310, and then transmits the fourth cipher key to the database 150, and may encrypt the fifth cryptographic key using the decrypted second cryptographic key. At this time, the received fourth encryption key may be stored in the memory allocated to the service management module 110, and may be deleted from the memory after the second encryption key stored in the database 150 is decrypted.

Meanwhile, according to an embodiment of the present invention, the service management module 110 may generate a checksum value for the data requested to be transmitted before the encryption of the data requested to be transmitted. At this time, the checksum value may use a hash function such as MD5 (Message-Digest algorithm 5), but various algorithms that can be used for data integrity verification besides MD5 can be used.

Thereafter, the service management module 110 transmits a data message to the service channel management unit 330 through the secure channel formed with the service channel management unit 310 (S1103). At this time, the secure channel may be a data channel formed through the process shown in FIG. 5, for example.

Meanwhile, the data message transmitted by the service management module 110 includes routing information, data encrypted with the fifth cryptographic key, a fifth cryptographic key encrypted using the second cryptographic key, and the APID of the application server 130 . ≪ / RTI > The routing information may also include a source and a destination of the data message. In this case, the source included in the routing information may be, for example, the ID (SMGID or SMIID) of the service management module 110, and the destination may be the DMID of the device management module 210, for example.

Meanwhile, according to the embodiment, the data message may further include a checksum value for the data requested to be transmitted.

Thereafter, the service channel manager 310 delivers the received data message to the device channel manager 330 (S1104). Specifically, the service channel management unit 310 identifies the access information of the device channel management unit 330 mapped to the DMID included in the routing information of the data message in the third routing table stored in the database 370, Information to the device-channel management unit 330. [0040]

Then, the device channel management unit 330 transmits a data message to the device management module 210 through the secure channel formed with the device management module 210 (S1105). In this case, the secure channel may be a data channel formed through the process shown in FIG. 3 or FIG. 5, for example.

Specifically, the device channel management unit 330 may transmit the data message to the device management module 210 based on the DMID included in the routing information of the data message.

Then, the device management module 210 stores the received data message in the database 250 (S1106).

Then, the device management module 210 decodes the data included in the received data message (S1107). Specifically, the device management module 210 can extract the DMID included in the data message and the second cryptographic key mapped to the APID in the database 250. Thereafter, the device management module 210 decrypts the fifth cryptographic key included in the data message using the extracted second cryptographic key, and decrypts the data included in the data message using the decrypted fifth cryptographic key have.

According to an embodiment of the present invention, the device management module 210 may encrypt the second cryptographic key using the third cryptographic key provided from the device channel management unit 330 and store the second cryptographic key in the database 250. The third encryption key may be generated by the device channel management unit 330 and stored in the database 370 of the message server 300 in the process of issuing the DMID shown in FIG. 330 may provide a third cryptographic key to the device management module 210 at the request of the device management module 210.

Specifically, the device management module 210 requests and receives a third encryption key from the device channel management unit 330, encrypts the second encryption key using the received third encryption key, and transmits the encryption key to the database 250 Can be stored. At this time, the received third encryption key may be stored in the memory allocated to the device management module 210, and the second encryption key may be deleted from the memory after encryption.

If the device management module 210 requests decryption of the fifth cryptographic key included in the data message, the device management module 210 requests and receives the third cryptographic key from the device channel management unit 330, The second cryptographic key stored in the database 250 can be decrypted using the decrypted second cryptographic key, and the fifth cryptographic key included in the data message can be decrypted using the decrypted second cryptographic key. At this time, the received third encryption key may be stored in the memory allocated to the device management module 210, and may be deleted from the memory after the second encryption key stored in the database 250 is decrypted.

If the received data message includes a checksum value, the device management module 310 calculates a checksum value from the decrypted data and compares the checksum value with a checksum value included in the data message The integrity of the data can be verified.

Then, the device management module 210 transmits an acknowledgment message to the device channel management unit 330 through the secure channel (S1108). At this time, the acknowledgment message may include the routing information and the data reception result. On the other hand, the routing information can be generated by switching the source and destination included in the routing information of the received data message.

On the other hand, if the data decryption is successful, or both the data decryption and the data integrity verification are successful according to the embodiment, the data reception result may include a code indicating that the data processing is successful. On the other hand, if data decryption fails or data integrity verification fails, the data reception result may include a code indicating that data processing has failed.

On the other hand, if the data decryption is successful, the device management module 210 delivers the decrypted data to the application client 230 (S1109). In this case, if a checksum value is included in the data message, the device management module 210 may transmit the decrypted data to the application client 230 when both the data decryption and the data integrity verification are successful .

Meanwhile, the device management module 210 deletes the data message stored in the database 250 after transmitting the acknowledgment message to the device channel management unit 330 (S1010).

Meanwhile, the device channel management unit 330 transmits an acknowledgment message to the service channel management unit 310 (S1111). Specifically, the device channel management unit 330 identifies the access information of the service channel management unit 310 mapped to the SMGID (or SMIID) included in the routing information of the acknowledgment message in the second routing table stored in the database 370 And then transmit the acknowledgment message to the service channel manager 310 using the access information identified.

Thereafter, the service channel manager 310 transmits an acknowledgment message to the service management module 110 via the secure channel based on the SMGID (or SMIID) included in the routing information of the acknowledgment message (S1112).

Thereafter, when the data processing is successful, the service management module 110 deletes the encrypted data stored in the database 150 and the encrypted fifth cipher key after confirming the data reception result included in the reception confirmation message (S1013 ). On the other hand, if the data processing has failed or the acknowledgment message is not received within the predetermined period, the service management module 110 can re-execute the process after step S1103.

12 is a block diagram illustrating and illustrating a computing environment including a computing device suitable for use in the exemplary embodiments. In the illustrated embodiment, each of the components may have different functions and capabilities than those described below, and may include additional components in addition to those described below.

The illustrated computing environment 1 includes a computing device 12. In one embodiment, computing device 12 may be one or more components included in message processing system 10.

The computing device 12 includes at least one processor 14, a computer readable storage medium 16, The processor 14 may cause the computing device 12 to operate in accordance with the exemplary embodiment discussed above. For example, processor 14 may execute one or more programs stored on computer readable storage medium 16. The one or more programs may include one or more computer-executable instructions, which when executed by the processor 14 cause the computing device 12 to perform operations in accordance with the illustrative embodiment .

The computer-readable storage medium 16 is configured to store computer-executable instructions or program code, program data, and / or other suitable forms of information. The program 20 stored in the computer-readable storage medium 16 includes a set of instructions executable by the processor 14. In one embodiment, the computer-readable storage medium 16 may be any type of storage medium such as a memory (volatile memory such as random access memory, non-volatile memory, or any suitable combination thereof), one or more magnetic disk storage devices, Memory devices, or any other form of storage medium that can be accessed by the computing device 12 and store the desired information, or any suitable combination thereof.

Communication bus 18 interconnects various other components of computing device 12, including processor 14, computer readable storage medium 16.

The computing device 12 may also include one or more input / output interfaces 22 and one or more network communication interfaces 26 that provide an interface for one or more input / output devices 24. The input / output interface 22 and the network communication interface 26 are connected to the communication bus 18. The input / output device 24 may be connected to other components of the computing device 12 via the input / output interface 22. The exemplary input and output device 24 may be any type of device, such as a pointing device (such as a mouse or trackpad), a keyboard, a touch input device (such as a touch pad or touch screen), a voice or sound input device, An input device, and / or an output device such as a display device, a printer, a speaker, and / or a network card. The exemplary input and output device 24 may be included within the computing device 12 as a component of the computing device 12 and may be coupled to the computing device 12 as a separate device distinct from the computing device 12 It is possible.

While the present invention has been particularly shown and described with reference to exemplary embodiments thereof, it is to be understood that the invention is not limited to the disclosed embodiments, but, on the contrary, I will understand. Therefore, the scope of the present invention should not be limited to the above-described embodiments, but should be determined by equivalents to the appended claims, as well as the appended claims.

1: Computing environment
12: computing device
14: Processor
16: Computer readable storage medium
18: Communication bus
20: Program
22: I / O interface
24: input / output device
26: Network communication interface
10: Message processing system
100: Application Service System
110, 110-1, 110-2, 110-3: service management module
130, 130-1, 130-2, and 130-3:
150, 370, 250, 250-1, 250-2:
200, 200-1, 200-2: User device
210, 210-1, 210-2, 210-3: Device Management Module
230, 230-1, 230-2, 230-3, 230-4: application client
300: message server
310, 310-1, 310-2: Service channel manager
330, 330-1, 330-2: Device channel manager
350: registration server

Claims (26)

One or more processors;
Memory; And
The method comprising: generating a TLS channel with a channel client through a Transport Layer Security (TLS) protocol; receiving a channel formation request message including an ID allocated to the channel client from the channel client over the TLS channel; And a channel manager for verifying the identity and transmitting a channel establishment response message to the channel client over the TLS channel according to the verification result to form a TLS-based secure channel.
The method according to claim 1,
Wherein the secure channel is a non-data channel with limited data message transmission.
The method of claim 2,
The channel management unit receives a channel upgrade request message including the ID allocated to the channel client and the ticket information of the channel client from the channel client over the secure channel, And transmits the channel upgrade response message to the channel client through the secure channel to change the communication channel to a data channel in which the data message is allowed to be transmitted.
The method according to claim 1,
Wherein the channel formation request message further includes ticket information of the channel client,
Wherein the channel management unit verifies the ID and the ticket information.
The method of claim 4,
Wherein the secure channel is a data channel in which data message transmission is allowed.
The method according to claim 3 or 4,
Wherein the ticket information comprises a ticket including seed information encrypted using a ticket key and a ticket key index for the ticket key.
The method of claim 6,
Wherein the channel management unit extracts a ticket key corresponding to a ticket key index included in the ticket information in a ticket key table including a plurality of ticket keys and a plurality of ticket key indexes corresponding to the plurality of ticket keys, Decrypting the ticket using the extracted ticket key, and verifying the ticket using the seed information included in the decrypted ticket.
The method of claim 7,
The seed information includes a ticket validity period,
Wherein the channel management unit verifies the ticket according to whether or not the ticket validity period has elapsed.
The method of claim 7,
Wherein the seed information includes an ID of a channel client that has issued the ticket,
Wherein the channel management unit verifies the ticket according to whether the ID included in the channel formation request message matches an ID included in the seed information.
The method according to claim 1,
Wherein the channel management unit transmits a channel establishment response message including an initial sequence number to the channel client when the verification is successful.
The method of claim 10,
Wherein the channel management unit checks a sequence number of a packet received from the channel client over the secure channel after forming the secure channel and if the sequence number is the same as the sequence number of a previously received packet, A device for forming a secure channel in a message processing system, which blocks the channel.
The method according to claim 1,
Wherein the channel client is a device management module.
The method according to claim 1,
Wherein the channel client is a service management module.
Creating a TLS channel with a channel client through a Transport Layer Security (TLS) protocol;
Receiving a channel establishment request message including an ID assigned to the channel client from the channel client over the TLS channel;
Verifying the identity; And
And generating a TLS-based secure channel by transmitting a channel establishment response message to the channel client over the TLS channel according to the verification result.
15. The method of claim 14,
Wherein the secure channel is a non-data channel with limited data message transmission.
16. The method of claim 15,
Receiving, through the secure channel, a channel upgrade request message including an ID assigned to the channel client and ticket information of the channel client from the channel client;
Verifying identity and ticket information included in the channel upgrade request message; And
Further comprising: transmitting a channel upgrade response message to the channel client over the secure channel to change the communication channel to a data channel permitting the data message transmission.
15. The method of claim 14,
Wherein the channel formation request message further includes ticket information of the channel client,
Wherein the verifying step verifies the identity and the ticket information.
18. The method of claim 17,
Wherein the secure channel is a data channel in which data message transmission is allowed.
16. The method according to claim 16 or 17,
Wherein the ticket information comprises a ticket containing seed information encrypted using a ticket key and a ticket key index for the ticket key.
The method of claim 19,
Wherein the step of verifying the identity and the ticket information comprises the steps of: receiving a ticket corresponding to a ticket key index included in the ticket information in a ticket key table including a plurality of ticket keys and a plurality of ticket key indexes corresponding to the plurality of ticket keys, Extracting a key;
Decrypting the ticket using the extracted ticket key; And
And verifying the ticket using seed information included in the decrypted ticket.
The method of claim 20,
The seed information includes a ticket validity period,
Wherein verifying the ticket verifies the ticket according to whether the ticket validity period has elapsed.
The method of claim 20,
Wherein the seed information includes an ID of a channel client that has issued the ticket,
Wherein the verifying the ticket verifies the ticket according to whether the ID included in the channel formation request message matches an ID included in the seed information.
15. The method of claim 14,
Wherein the forming comprises transmitting a channel formation response message including an initial sequence number to the channel client when the verification is successful.
24. The method of claim 23,
Confirming a sequence number of a packet received from the channel client over the secure channel after the forming; And
Further comprising blocking the secure channel if the sequence number is equal to a sequence number of a previously received packet.
15. The method of claim 14,
Wherein the channel client is a device management module.
15. The method of claim 14,
Wherein the channel client is a service management module.

Images