KR20120134943A

KR20120134943A - Method for authentication pipe in multi-host environment, and host controller therefor

Info

Publication number: KR20120134943A
Application number: KR1020110054199A
Authority: KR
Inventors: 김경태; 이진형
Original assignee: 주식회사 케이티
Priority date: 2011-06-03
Filing date: 2011-06-03
Publication date: 2012-12-12

Abstract

PURPOSE: An authentication method for a pipe in a multi-host terminal and a host controller therefor are provided to prevent a dynamically assigned pipe from being deleted through a non-authorized third host in a multi-host environment having an UICC(universal integrated circuit card) host, a terminal host, and one or more additional hosts. CONSTITUTION: A first host which generates a specific dynamic pipe transmits a pipe generation command to the host controller(S310). The host controller transmits an ADM_CREATE_PIPE command response, which includes an authentication code for a corresponding pipe as a parameter, to the first host(S320). The host controller transmits an ADM_NOTIFY_PIPE_CREATE command response, which includes the authentication code as the parameter, to a second host which is a counterpart host for the corresponding pipe(330). The second host which is the counterpart host for the corresponding pipe transmits an ANY_OK, which is a response having no parameter, to the host controller(S340). [Reference numerals] (AA) Start; (BB) End; (S310) Generating ADM_CREATE_PIPE command and transmitting command to host controller by first host; (S320) Transmitting response including authentication code as parameter by host controller; (S330) Generating ADM_NOTIFY_PIPE_CREATE command which includes authentication code and transmitting command to second host; (S340) Transmitting response without parameter to host controller by second host

Description

Method for authentication pipe in multi-host terminal, and host controller therefor {Method for Authentication Pipe in Multi-host Environment, and Host Controller therefor}

The present specification relates to a host controller interface of a terminal having a multi-host including a universal integrated circuit card (UICC) host and a terminal host and an additional host. It also relates to a technique for authenticating a particular pipe in a multihost environment with additional hosts in addition to the UICC and terminal host.

Used as a smart card in wireless communication systems such as GSM and Universal Mobile Telecommunication System (UMTS), such as UICC or Universal Subscriber Identity Module (USIM), which is responsible for the integration and security of all kinds of personal information. It usually has a capacity of hundreds of KBytes or more.

UICC includes Subscriber Identity Module (SIM) applications on GSM networks, Universal Subscriber Identity Module (USIM) applications on UMTS networks, and other applications that can access both GSM and UMTS networks, or address books (Phonebooks) or Can be used as storage for other applications.

Meanwhile, in the terminal including the UICC, a host controller is used for control between the UICC host and the terminal host, which may be defined as a host controller or a host controller interface (HCI).

However, as discussed so far, the HCI inside the terminal including the UICC only defines the connection and communication control between the two hosts, the UICC host and the terminal host (or terminal host). There is no consideration for a multi-host environment such as an additional host provided in the terminal.

Therefore, the present specification provides a technique for protecting a specific pipe by providing an authentication mechanism for control between the host controller and the multi-host, specifically, a pipe between the gates of two arbitrary hosts in a multi-host environment. Suggest.

One embodiment of the present invention provides a pipe authentication method in a multi-host terminal including a UICC host, a terminal host, one or more additional hosts and a host controller.

In another embodiment of the present invention, associated management commands for CREATE and DELETE pipes for pipe authentication at a multi-host terminal including a UICC host, a terminal host, one or more additional hosts and a host controller. It provides a method for adding a pipe authentication parameter as a parameter of.

In order to achieve the above object, an embodiment of the present specification is a pipe authentication method in a terminal having a UICC host, a terminal host, one or more additional hosts and a host controller, wherein the host controller is a first host of the hosts. Pipe authentication including receiving a pipe creation command (ADM_CREATE_PIPE) for a specific dynamic pipe from and generating and sending a response (ANY_OK) including an authentication code for the generated pipe as a parameter to the first host. Provide a method.

According to another embodiment of the present invention, a pipe authentication method in a terminal having a UICC host, a terminal host, one or more additional hosts, and a host controller, wherein the delete request host that wants to delete a specific dynamic pipe receives an authentication code. Generating and transmitting a pipe delete command (ADM_DELETE_PIPE) including the parameter to a host controller; an authentication step of the host controller performing authentication on the authentication code included in a pipe delete command parameter; It provides a pipe authentication method comprising generating a response to the pipe delete command and transmitting to the delete request host.

According to another embodiment of the present invention, in a multi-host terminal including a UICC host, a terminal host, one or more additional hosts, and a host controller, a deletion request host that wants to delete a specific dynamic pipe includes an authentication code as a parameter. Generating and transmitting a pipe delete command (ADM_DELETE_PIPE) to a host controller; generating and transmitting a pipe delete notification command (ADM_NOTIFY_PIPE_DELETE) including the authentication code as a parameter to the target host; The host provides an authentication method for an authentication code included in an ADM_NOTIFY_PIPE_DELETE command, and the target host generates a response signal for the authentication result and transmits the response signal to a host controller.

According to another embodiment of the present invention, a pipe authentication method in a terminal having a UICC host, a terminal host, one or more additional hosts, and a host controller,

A first host of the host transmits a pipe creation command (ADM_CREATE_PIPE) for a specific dynamic pipe to a host controller, and the host controller generates a pipe creation notification command (ADM_NOTIFY_PIPE_CREATE) so that the second host is the other host of the corresponding pipe. And transmitting to the terminal, wherein at least one parameter of the ADM_CREATE_PIPE command and the ADM_NOTIFY_PIPE_CREATE command includes an authentication code having a predetermined length corresponding to the generated pipe identifier.

According to another embodiment of the present invention, a pipe authentication method in a terminal having a UICC host, a terminal host, one or more additional hosts, and a host controller, wherein the host controller attempts to delete a specific dynamic pipe. Receiving a pipe delete command (ADM_DELETE_PIPE) including a pipe identifier of a pipe to be deleted from the host as a parameter, and generating a response to the pipe delete command and transmitting the response to the delete request host; The parameter of the command provides a pipe authentication method further including an authentication code of a predetermined length.

According to another embodiment of the present invention, a pipe authentication method in a terminal having a UICC host, a terminal host, one or more additional hosts, and a host controller, wherein the host controller attempts to delete a specific dynamic pipe. After receiving the pipe delete command (ADM_DELETE_PIPE) from the host, generating a pipe delete notification command (ADM_NOTIFY_PIPE_DELETE) including the pipe identifier of the pipe to be deleted as a parameter and transmitting to the target host, and from the target host to the ADM_NOTIFY_PIPE_DELETE command And receiving a response, wherein the ADM_NOTIFY_PIPE_DELETE command parameter includes an authentication code of a predetermined length.

According to another embodiment of the present invention, a host controller for generating and notifying generation of a specific dynamic pipe in association with a UICC host, a terminal host, and one or more additional hosts, wherein the host controller is configured to transmit a specific dynamic pipe from a first host. Receives the pipe creation command (ADM_CREATE_PIPE) for the pipe, generates a response (ANY_OK) including the authentication code for the generated pipe as a parameter and sends it to the first host, and generates a pipe creation notification (ADM_NOTIFY_PIPE_CREATE) command to the pipe The host controller transmits to the second host, which is a counterpart host, but includes an authentication code corresponding to the generated pipe identifier as a parameter of the ADM_CREATE_PIPE command and the ADM_NOTIFY_PIPE_CREATE command.

According to another embodiment of the present invention, a host controller for deleting a specific dynamic pipe by interworking with a UICC host, a terminal host, and one or more additional hosts, and a delete request for deleting a specific dynamic pipe Receives a pipe delete command (ADM_DELETE_PIPE) including a pipe target to be deleted from a host, generates a response to the pipe delete command, and transmits the response to the delete request host, wherein an authentication code of a predetermined length is included as a parameter of the ADM_DELETE_PIPE command. Provides a host controller.

According to another embodiment of the present invention, a host controller that performs a delete notification on a specific dynamic pipe in association with a UICC host, a terminal host, and one or more additional hosts, wherein the deletion is intended to delete a specific dynamic pipe. After receiving the pipe delete command (ADM_DELETE_PIPE) from the requesting host, a pipe delete notification command (ADM_NOTIFY_PIPE_DELETE) is generated and transmitted to the target host including the pipe identifier of the pipe to be deleted as a parameter, and from the target host for the ADM_NOTIFY_PIPE_DELETE command. Provide a host controller that receives the response but includes an authentication code of a predetermined length as a parameter of the ADM_NOTIFY_PIPE_DELETE command.

1 illustrates an example of a host controller interface architecture of a multi-host environment to which an embodiment of the present invention can be applied.
2A and 2B show an example of configuration of an HCP packet and an HCP message to which an embodiment of the present invention is applied, respectively.
3 is a flowchart illustrating a pipe generation method of a pipe authentication method using an authentication code according to an embodiment of the present invention.
4 is a view illustrating a pipe deletion flow according to a first method of a pipe deletion authentication method using an authentication code according to an embodiment of the present invention.
5 illustrates a pipe deletion flow according to a second method of the pipe deletion authentication method using the authentication code according to an embodiment of the present invention.

Hereinafter, some embodiments will be described in detail with reference to exemplary drawings. In adding reference numerals to the components of each drawing, it should be noted that the same reference numerals are assigned to the same components as much as possible even though they are shown in different drawings. In the following description of the embodiments of the present invention, a detailed description of known functions and configurations incorporated herein will be omitted when it may make the subject matter of the present disclosure rather unclear.

In addition, the present specification describes a wireless communication system as an example, and the work performed in the wireless communication is characterized in that it includes all the operations performed in the system that controls the wireless communication and the wireless communication device that transmits data with the system.

1 illustrates an example of a host controller interface architecture of a multi-host environment to which an embodiment of the present invention can be applied.

HCI stands for a logical interface that allows the use of a contactless application hosted on a UICC. In particular, control of a host (ie, a UICC host, an additional host, etc.) mounted inside a UICC connected to a host controller embedded in a contactless front end (hereinafter referred to as "CLF") of the terminal. To do that.

These HCIs can be broadly divided into two parts: HCI cores and contactless platforms, where HCI cores specify logical interfaces that are independent of specific applications, and contactless platforms can be used to implement HCI cores for specific contactless applications using UICC and CLF. It is related.

In addition, a low-level protocol for supporting HCI may be separately defined, for example, Single Wire Protocol (SWP).

In the present specification, the length of all data is in bytes unless otherwise specified, and each byte is represented by b8 to b1 (b8 is the leftmost bit). Hexadecimal values are indicated by a single expression, such as '1F'.

In one embodiment of the invention, one or more hosts are physically connected to the host controller, and the HCI defines the interface between the hosts.

As shown in FIG. 1, the HCI architecture is defined by three major levels: a set of gates, a Host Controller Protocol (HCP) messaging mechanism, and an HCP routing mechanism. Each gate exchanges commands, responses, and events, and the HCP routing mechanism. Can be split into messages if necessary.

In other words, as shown in FIG. 1, the multi-host HCI architecture is a host controller 130 that performs connection control between an arbitrary first host 110, a second host 120 connected thereto, and two hosts. It can be composed of).

The first host 110 and the second host 120 may be selected from one or more additional hosts or dynamic allocation hosts in addition to the UICC host and the terminal host.

That is, only two hosts are shown in FIG. 1, but there are three or more multi-hosts (UICC host, terminal host, and one or more additional hosts) in the actual terminal, and in FIG. 1, pipes are created between the gates. Only two hosts in the connected state are shown.

Each of the first host 110 and the second host 120 has a lower level of physical and data link layers 111 and 121, an HCP routing layer 112 and 122, an HCP messaging layer 113 and 123, and a gate. It may have a stack structure of layers 114 and 124.

If one of the first host 110 and the second host 120 is a UICC host, the arbitrary physical and data link layer may be a SWP layer, and in the case of a terminal host and an additional host, the host controller 130 It may be the same physical and data link as the physical and data layer structure.

The host controller 130 performs a function of mediating packet transmission between the UICC host and the terminal host in the physical and data link layer and the HCP routing layer. The host controller 130 includes predetermined physical and data for the connection with the first host 110. It includes a link layer (SWP layer when the first host is a UICC host) and an arbitrary physical / data link layer for connection with the second host 120, and includes an HCP routing layer thereon.

For proper operation, the HCP has a data link layer beneath it, and the data link layer (e.g. SWP) is error free and orderly receive / transmit is preferred, and provides unique data flow control. A packet of a layer is delivered with a maximum size unique to a data link layer, and the size of each received packet is reported to an upper layer.

In an embodiment of the present invention, it is assumed that the host connected to the host controller is provided with a dynamically assigned host or an additional host other than the UICC host and the terminal host.

As an example of such a dynamic allocation host or additional host, an embedded secure element host, an SD card secure element host, a fixed secure element, and an external removable secure element of the terminal Secure Element), Internal Removable Secure Element, Terminal Software Native Application, Terminal Java Applet, Remote Over the Air (OTA) Application, etc., but is not limited thereto. In addition to the UICC host and terminal host It should be understood as a concept that includes all kinds of hosts that need to be controlled by the host controller.

Each host will host identity; is not defined in _{(Host Identity H ID), H} ID) may be defined as shown in the following Table 1 are not limited to.

[Table 1]

Host ID table

In this specification, 'host' refers to all logical hosts except for the host controller (eg, UICC host, terminal host, additional host, etc.).

In Table 1, '10' to '1F' are used as host IDs of the dynamic allocation host, but the present invention is not limited thereto. The reserved for future use (RFU) means a host ID reserved for future use.

The gate provides an entry point of a service operated inside each host. HCP allows gates to exchange messages from other hosts, and there are two types of gates: a management gate and a generic gate.

The management gate is used for the management of the host network, the generic gate is independent of the management of the host network and the characteristics are defined only within the HCI core.

The gate type is classified by a gate identifier, and the gate identifier may be defined as shown in Table 2 below.

[Table 2]

Example of a gate identifier

The gate identifier may be uniquely defined within the range of the host (from '10' to 'FF') or may have the same value as the same gate type of all hosts ('00' to '0F').

The host and the gate may have the following characteristics.

Every host and host controller must have one administration gate, every host can have one link management gate and the host controller must have one link management gate.

In addition, every host and host controller should have one identity management gate and one loop back gate, and may have one or more generic gates.

Meanwhile, 'pipe' is defined as a logical communication channel between two gates.

There are two types of pipes: static pipes and dynamic pipes. Static pipes are always available and do not need to be created or deleted, and dynamic pipes can be created and deleted. Can be.

The state of the pipe can be open (open) or closed (closed) and must be maintained continuously until the host power is down and back up. The state of the pipe must remain persistent as long as the host is temporarily removed from the host network and not replaced by another device. The state of dynamic pipes immediately after their creation and the initial state of static pipes should always be closed.

Pipe Identifier P _ID is 7 bits long and the value of P _ID is used in the head of the HCP packet as routing information. The pipe identifiers of the static pipes are predefined as shown in Table 3 below, and the pipe identifiers of the dynamic pipes are dynamically allocated by the host controller.

[Table 3]

Static Pipe Identifier (P _ID )

Static pipes always connect the gates of the host and the gates of the host controller, while dynamic pipes connect the two gates of the other hosts. Static pipes and dynamic pipes can connect different types of gates, as shown in Table 3, and dynamic pipe identifiers are uniquely defined within the host network.

Registry templates are associated with every gate, and the registry templates define gate-related parameters. A parameter is identified by a parameter identifier consisting of 1 byte, and the parameter identifier is uniquely defined within the range of the gate.

The parameter identifiers of all the gates are defined within the range of '00' to 'EF', and the parameter identifiers in the range of 'F0' to 'FF' may be used for a proprietary purpose.

For each pipe connected to the gate, a new instance of the registry is created. When creating a pipe, the Access Rights Read-Write or Write-Only parameters of all registry parameters are the default values. Is set. The Read-Only (RO) parameter may be set to an appropriate value different from the default value.

The host is responsible for managing the registry concerned, and the registry's persistence and default values are dictated by each registry description.

When a pipe is deleted, its registry instance is also deleted.

The HCP packet transmitted and received between each host and the host controller may have a format as shown in FIG. 2A.

That is, each host may transmit / receive an HCP packet having a format as shown in FIG. 2 with a host controller using a data link layer.

The HCP packet may be divided into a packet head and a message area. The packet head may be further divided into a CB (Chaining Bit) field of 1 bit (b8) and a pID field of 7 bits (b7 to b1). It can consist of a total of n byte field values.

The CB field has a value of 1 unless a message fragmentation is used as a coupling bit, and pID is a pipe identifier.

The host controller forwards the packet to the destination host using the pID field value. The destination host forwards the packet to the destination gate, which allows any two gates connected by a pipe to exchange messages using this mechanism.

2B shows an example of an HCP message structure.

The HCP message includes one instruction information and optionally data.

The HCP message may be composed of an 8-bit head and n bytes of data, and the head may be composed of a type field of 2 bits (b8 and b7) and an indication field of 6 bits (b6 to b1).

The type field is for indicating a type of indication, and the indication field is for indicating specific indication information.

Types of instructions include a command (Type value 0), an event (Type value 1), a response to the command (Type value 2), and the like. Type value 3 is reserved for future use. .

The indication field value authorizes commands, events, and responses, and all three types can transfer data.

The data field structure for indication information included in the HCP message of FIG. 2B may be defined in the form of various tables.

Table 4 is a list of all kinds of commands (words) that can be included in an HCP message, and the meaning of each command applies equally to all gates.

[Table 4]

Commands Included in HCP Messages

As shown in Table 4, the command may be classified into a generic command applied to all gates and an administration command required for managing the host network as shown in FIG. 1.

In an embodiment of the present invention, the host network further includes a dynamic allocation host in addition to the UICC host. In this case, the comprehensive command defined in the host network environment including only the UICC host and the terminal host does not change. There is only a difference.

Therefore, descriptions of attributes such as description and length of the comprehensive commands ANY_SET_PARAMETER, ANY_GET_PARAMETER, ANY_OPEN_PIPE, and ANY_CLOSE_PIPE defined in Table 42 are omitted, for example, defined in ETSI SCP standard TS 102 622. It may be configured as.

On the other hand, when the management commands are roughly shown, ADM_CREATE_PIPE is used by the host to request the host controller to create a new dynamic pipe between two gates, and ADM_NOTIFY_PIPE_CREATED is used to generate the dynamic pipe to the destination host of the pipe where the host controller is created. ADM_DELETE_PIPE is a command used by the host to notify the host controller about deleting a dynamic pipe. ADM_NOTIFY_PIPE_DELETED command is a command sent by the host controller to the host to notify the deletion of a dynamic pipe. .

Each management command may have a command parameter, and a component that receives each command may give a predetermined response according to a processing result. The response may include an ANY_OK response indicating that the processing is completed normally and a plurality of error responses indicating that the processing is not completed. The types and meanings of the error responses will be described below. In addition, the response may also include a predetermined parameter (response parameter).

In addition, in addition to the management commands of Table 4, ADM_CREATE_MH_PIPE, ADM_ALLOCATE_HOST, etc., are added for dynamic allocation and pipe generation of additional hosts in a multi-host environment. The ADM_ALLOCATE_HOST command is used by a particular host to request a dynamic allocation host ID when there is no currently assigned host ID. The ADM_CREAT_MH_PIPE command contains the source host ID, and the dynamic allocation host (that is, an additional host). The new host network has the same characteristics as ADM_CREATE_PIPE, except that it is used in preference to ADM_CREATE_PIPE.

Meanwhile, in the multi-host environment as shown in FIG. 1, each of the multi-hosts may be connected to the host controller through a single physical interface, and only logical partitioning by HCI may be provided. Therefore, if there is a Delete or Clear command for a specific pipe from another host, the important pipe may be deleted by another host.

That is, until now only two hosts, a UICC host and a terminal host, have been considered. Since a pipe is also created only between the two hosts, another third host could not delete the pipe.

However, in a multi-host terminal where three or more hosts are connected by a single physical interface, as currently discussed, the host controller from which the specific dynamic pipe was created and a third host other than the destination host issued a delete command for the opposite pipe. This can be a problem because you can send it to. That is, as will be described later, according to the present specification, the pipe delete command ADM_DELETE_PIPE has only a pipe identifier as a parameter and does not include information of the requesting host requesting the delete command. It is not.

Thus, if there is a delete or clear command from another host for a particular pipe of interest, then a mechanism is needed to authenticate that such delete or clear command is authorized to delete or clear that pipe.

Therefore, in an embodiment of the present invention, the ADM_CREATE_PIPE command parameter, the response parameter of the ADM_CREATE_PIPE command, the ADM_NOTIFY_PIPE_CREATED command parameter, the ADM_DELETE_PIPE command parameter, and the ADM_NOTIFY_PIPE_DELETED command parameter, respectively, for authentication of a pipe between any two gates in a multihost environment. It is characterized by adding an authentication code (Authentication Code) for the pipe.

Hereinafter, each administration command used in one embodiment of the present invention will be described in detail.

ADM_CREATE_PIPE is a command used by the host to request the host controller to create a new dynamic pipe between two gates. The host requesting the pipe is the source host and the host controller can check whether the source host has the authority to create the pipe by using the white list defined by the destination host.

The service that can be used on the pipe is determined by the destination gate, and any gate identifier can be used as the source gate.

The ADM_CREATE_PIPE command parameter can be defined as shown in Table 5 below.

[Table 5]

ADM_CREATE_PIPE command parameter

Of course, in a multi-host environment, the source host ID (source H _ID ) may be added to the ADM_CREATE_PIPE command parameter to identify the source host.

If the pipe is created successfully, the host controller sends a response ANY_OK to the source host with the parameters shown in Table 6 below.

TABLE 6

ANY_OK response parameter for the ADM_CREATE_PIPE command

The authentication code is generated by the host controller when the host controller creates the dynamic pipe, and may be a random number. The authentication code may have a length of one or two bytes, but is not necessarily limited to such length.

This authentication code is used to determine whether the delete command for the generated pipe is appropriate.

That is, according to an embodiment of the present invention, a specific authentication code is given to a pipe created by the ADM_CREATE_PIPE command, transmitted to the source host and the destination host of the pipe, and later, the authentication code is used as an essential parameter in the pipe delete command. By defining it, you are authorizing the authority to delete dynamic pipes.

ADM_NOTIFY_PIPE_CREATED according to an embodiment of the present invention is a command used by the host controller to notify the destination host of the creation of a dynamic pipe. The ADM_NOTIFY_PIPE_CREATED command parameter can be defined as shown in Table 7 below.

[Table 7]

ADM_NOTIFY_PIPE_CREATED command parameter

That is, according to an embodiment of the present invention, the ADM_NOTIFY_PIPE_CREATED command parameter includes the same authentication code as included in the pipe creation response.

Thus, the source host and destination host of the dynamic pipe can identify or include the same authentication code included in the ADM_CREATE_PIPE command response parameter and the ADM_NOTIFY_PIPE_CREATED command parameter, respectively, as described again below, the pipe delete command and notification thereof. By including the authorization code in the command, you have an authentication mechanism.

On the other hand, when the destination host receiving the ADM_NOTIFY_PIPE_CREATED command accepts the creation of the pipe, it sends an ANY_OK response to the host controller without parameters.

ADM_DELETE_PIPE is a command for a host that wants to delete a specific pipe to request a dynamic pipe delete from the host controller. The host that requested the deletion of the pipe may be either the source host or the destination host.

The ADM_DELETE_PIPE command parameter may be defined as shown in Table 8.

[Table 8]

ADM_DELETE_PIPE command parameter

As shown in Table 8, according to an embodiment of the present invention, the ADM_DELETE_PIPE command parameter includes an authentication code assigned to the pipe in addition to the pipe identifier (P _ID ).

That is, a unique authentication code is assigned to the pipe during the above-described pipe creation and creation notification process, and the same authentication code must be included in the delete command of the pipe as a parameter.

On the other hand, since the host controller receiving the ADM_DELETE_PIPE command already knows the authentication code assigned to the pipe, the host controller checks whether the authentication code included in the ADM_DELETE_PIPE command parameter is legitimate, and deletes the pipe if there is legitimate authority. If not, the server responds with an error response (an error response with the ANY_E_PIPE_AUTH_FAIL response code indicating that the pipe deletion was rejected by the authentication code) without deleting the pipe.

If the pipe is successfully deleted, the host controller sends an ANY_OK response with no parameters.

The ADM_NOTIFY_PIPE_DELETED command is a command that the host controller sends to the host to notify the deletion of the dynamic pipe, and the ADM_NOTIFY_PIPE_DELETED command parameter may be defined as shown in Table 9 below. The host receiving the ADM_NOTIFY_PIPE_DELETED command may be a counterpart host of the host requesting the deletion of the pipe.

TABLE 9

ADM_NOTIFY_PIPE_DELETED command parameter

According to an embodiment of the present invention, an ADM_NOTIFY_PIPE_DELETED command parameter includes an authentication code assigned to the pipe in addition to the pipe identifier P _ID .

Therefore, since the host that received the ADM_NOTIFY_PIPE_DELETED command already knows the authentication code assigned to the pipe, if the delete permission is authenticated compared to the authentication code included in the command parameter, the pipe is successfully deleted and ANY_OK without the parameter. Send a response to the host controller.

Of course, if the deletion authority is not authenticated by the authentication code, the above-described error response is transmitted to the host controller without deleting the pipe.

As described above, according to an embodiment of the present invention, the authentication parameters for the corresponding pipes in the response parameter of ADM_CREATE_PIPE, the ADM_NOTIFY_PIPE_CREATED command parameter, the ADM_DELETE_PIPE command parameter, and the ADM_NOTIFY_PIPE_DELETED command parameter, respectively, for authentication of a pipe between any two gates in a multihost environment. By adding an Authentication Code and authenticating the authority to delete a specific dynamic pipe through it, it is possible to prevent a host other than the source host or destination host of the pipe from deleting the pipe without authorization.

On the other hand, the host or host controller that has received each command or response as described above should make a predetermined response according to the processing result, and the types of the response are shown in Table 10 below.

That is, there is an ANY_OK response indicating that the response is normally processed and an error response when the response is not normally processed. The error response may be in various forms as shown in Table 10 depending on the type of error.

[Table 10]

Types of Responses to Administrative Commands

Among them, ANY_E_PIPE_AUTH_FAIL, an error code indicating that the pipe deletion is rejected by the authentication code, is added in the present invention. The rest of the error codes are the same as defined so far, so descriptions are omitted to avoid duplication.

Meanwhile, Table 11 below illustrates response codes of error responses available for each management command.

TABLE 11

Response codes available for each administrative command

That is, when an authentication code is used according to an embodiment of the present invention, ANY_E_PIPE_AUTH_FAIL, which is an error code indicating that the pipe deletion is denied by the authentication code, is an error response to the ADM_DELETE_PIPE command and the ADM_NOTIFY_PIPE_DELETE command related to pipe deletion. Can be used as

Meanwhile, in the above-described embodiment, the authentication code is generated and managed by the host controller during the pipe generation process. However, the host controller is only responsible for transmitting and receiving the message, and generating and generating the authentication code when the pipe is generated. Verification of the authentication code when deleting the pipe may be implemented in a form performed by the corresponding host.

That is, unlike the Table 5 described above, the ADM_CREATE_PIPE command parameter may be in a form including an authentication code for a pipe to be generated as shown in Table 12 below.

That is, a host (first host) that wants to create a pipe may randomly generate an authentication code of 1 or 2 bytes (which may be variable in length) to be used for the pipe to be generated, and deliver it to the host controller as an ADM_CREATE_PIPE command parameter.

[Table 12]

Another embodiment of the ADM_CREATE_PIPE command parameter

In this case, the ANY_OK response parameter for the ADM_CREATE_PIPE command may be as shown in Table 6 above, or may be in a form without an authentication code as shown in Table 13 below. In this embodiment, since the first host requesting pipe creation already knows the authentication code for the corresponding pipe (since it has been generated by itself), the host controller receives only the pipe identifier and matches the authentication code for the pipe. It can be managed.

[Table 13]

Another embodiment of the ANY_OK response parameter for the ADM_CREATE_PIPE command

In addition, in the pipe deletion process, the first method in which the host controller plays a role in the verification and authorization of the authentication code, and the host controller only performs the role of intermediary of the message and hosts the verification and deletion authority authentication function of the authentication code. May be implemented in a second manner.

In the first method, the host controller manages the authentication code generated by the host controller during the pipe creation process or received from the first host by matching it with the corresponding pipe identifier, and whether the authentication code included in the pipe delete command (ADM_DELETE_PIPE) is valid. It is your own judgment. If it is determined that the authentication code is not valid (that is, when the authentication code included in the ADM_DELETE_PIPE is different from the authentication code corresponding to the pipe identifier managed by the ADM_DELETE_PIPE), an error response (ANY_E_PIPE_AUTH_FAIL) is transmitted to the requesting host.

Meanwhile, in the second method, the host controller receives the ADM_DELETE_PIPE command and then uses the authentication code included therein to generate the ADM_NOTIFY_PIPE_DELETED command and transmit it to the target host as shown in Table 9, and the target host authenticates included in the ADM_NOTIFY_PIPE_DELETED command parameter. You can check the delete permission by comparing the code with the authentication code of the pipe that you already know. If there is no delete authority (ie, two authentication codes are different), the target host sends an error response (ANY_E_PIPE_AUTH_FAIL) to the host controller in response to the ADM_NOTIFY_PIPE_DELETED command, and the host controller sends the error response as it is, ADM_DELETE_PIPE. In response to the command, it can be sent to the host requesting the deletion.

In the second embodiment, the target host receiving the ADM_NOTIFY_PIPE_DELETED command is preferably the destination host for the pipe, but is not limited thereto and may be the source host of the pipe or both the source and destination host.

As described above, the basic idea of the present invention is to include an authentication code for each pipe in the multi-host terminal, and to include all configurations that can prevent unauthorized hosts from deleting the pipe, and various configurations for implementing the same These are just examples and the present invention should not be construed as being limited to such examples.

3 is a flowchart illustrating a pipe generation method of a pipe authentication method using an authentication code according to an embodiment of the present invention.

According to an embodiment of the present invention, in a multi-host terminal including a UICC host, a terminal host, one or more additional hosts, and a host controller, the first host to create a specific dynamic pipe first issues a pipe creation command (ADM_CREATE_PIPE) to the host controller. In step S310, and after generating the corresponding dynamic pipe, the host controller transmits an ADM_CREATE_PIPE command response including the authentication code for the pipe as a parameter to the first host (S320). In operation S330, the host controller generates an ADM_NOTIFY_PIPE_CREATE command including the authentication code as a parameter and transmits the generated ADM_NOTIFY_PIPE_CREATE command to a second host, which is a counterpart host of the corresponding pipe.

In this case, the first host and the second host may be any one of multiple hosts.

In addition, the authentication code is a random number having a length of 1 or 2 bytes, generated by the first host or the host controller, and may be given a value unique to the generated pipe.

The ADM_CREATE_PIPE command response parameter and the ADM_NOTIFY_PIPE_CREATE command parameter may include, in addition to the authentication code, a 7-bit long pipe identifier (P _ID ) for the generated pipe.

Of course, the second host, which is the other host of the corresponding pipe, may further include a step S340 of normally generating a pipe and transmitting ANY_OK, which is a parameterless response, to the host controller.

In addition, the authentication code may be generated by the first host and transmitted as a pipe generation command (ADM_CREATE_PIPE) parameter of step S310, or may be generated by the host controller in step S320.

4 is a view illustrating a pipe deletion flow according to a first method of a pipe deletion authentication method using an authentication code according to an embodiment of the present invention.

In a multi-host terminal including a UICC host, a terminal host, one or more additional hosts, and a host controller, a delete request host (ADM_DELETE_PIPE) including an authentication code as a parameter is first performed by a delete request host that wants to delete a specific dynamic pipe. Generating and transmitting to the host controller (S410), an authentication step (S420) in which the host controller performs authentication on the authentication code included in the pipe delete command parameter, and generating a response to the pipe delete command; And transmitting to the deletion request host (S430).

In addition, when the authentication for the authentication code is successful in step S420, it may further include the step of generating a pipe delete notification command (ADM_NOTIFY_PIPE_DELETE) to transmit to the target host (S440).

Here, the target host is preferably a destination host for the pipe, but is not limited thereto, and may be a source host of the pipe or both a source and a destination host.

For the first method as shown in FIG. 4, the host controller must store and manage the authentication code acquired in the pipe creation process as shown in FIG. 3 with the corresponding pipe identifier, and the host controller is included in the ADM_DELETE_PIPE command parameter at step S420. It is checked whether the authentication code is a valid authentication code for the pipe identifier to be deleted.

5 illustrates a pipe deletion flow according to a second method of the pipe deletion authentication method using the authentication code according to an embodiment of the present invention.

In a multi-host terminal including a UICC host, a terminal host, one or more additional hosts, and a host controller, a delete request host (ADM_DELETE_PIPE) including an authentication code as a parameter is first performed by a delete request host that wants to delete a specific dynamic pipe. Generating and transmitting to the host controller (S510), the host controller generates a pipe delete notification command (ADM_NOTIFY_PIPE_DELETE) including the authentication code as a parameter and transmitting to the target host (S520), and the target host Performing an authentication on the authentication code included in the ADM_NOTIFY_PIPE_DELETE command (530); generating, by the target host, a response signal for the authentication result, and transmitting the generated response signal to the host controller (S540); Response signal received from the ADM_DELETE_PIPE command. As a response may be configured to include a step (S550) of transmitting to the delete request host.

In the second method as shown in FIG. 5, since the target host is the source or destination host of the pipe requested to be deleted, the target host already has an authentication code for the pipe in the process of generating the pipe as shown in FIG. 3. Therefore, the authority for deleting the pipe can be confirmed by comparing the authentication code transmitted by the host for requesting deletion with a valid authentication code already owned by the host.

The response signals in S540 and S550 may be an ANY_OK response without parameters when the pipe deletion is successful, and an ANY_E_PIPE_AUTH_FAIL response when an error occurs due to a mismatch in the authentication code.

In FIG. 4 and FIG. 5, the authentication code is a random number having a length of 1 or 2 bytes, and may be given a value unique to the pipe.

In addition to the authentication code, the ADM_DELETE_PIPE command parameter and the ADM_NOTIFY_PIPE_CREATE command parameter may include a 7-bit long pipe identifier (P _ID ) for the generated pipe.

Using the above embodiments, there is an effect of preventing an unauthorized third party from deleting a dynamically allocated pipe arbitrarily in a multi-host environment having a UICC host, a terminal host, and one or more additional hosts.

While the present invention has been described in connection with what is presently considered to be the most practical and preferred embodiments, it is to be understood that the invention is not limited to the disclosed embodiments. In other words, within the scope of the present invention, all of the components may be selectively operated in combination with one or more. In addition, although all of the components may be implemented as one independent hardware, some or all of the components may be selectively combined to perform a part or all of the functions in one or a plurality of hardware. As shown in FIG.

It is also to be understood that the terms such as " comprises, "" comprising," or "having ", as used herein, mean that a component can be implanted unless specifically stated to the contrary. But should be construed as including other elements. All terms, including technical and scientific terms, have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs, unless otherwise defined. Commonly used terms, such as predefined terms, should be interpreted to be consistent with the contextual meanings of the related art, and are not to be construed as ideal or overly formal, unless expressly defined to the contrary.

The foregoing description is merely illustrative of the technical idea of the present invention, and various changes and modifications may be made by those skilled in the art without departing from the essential characteristics of the present invention. Therefore, the embodiments disclosed in the present invention are intended to illustrate rather than limit the scope of the present invention, and the scope of the technical idea of the present invention is not limited by these embodiments. The protection scope of the present invention should be interpreted by the following claims, and all technical ideas within the equivalent scope should be interpreted as being included in the scope of the present invention.

Claims

A pipe authentication method in a terminal having a UICC host, a terminal host, one or more additional hosts, and a host controller, the host controller comprising:
Receiving a pipe creation command (ADM_CREATE_PIPE) for a specific dynamic pipe from a first host of the hosts;
And generating a response (ANY_OK) including an authentication code for the generated pipe as a parameter and transmitting it to the first host.

The method of claim 1,
The authentication code is a pipe authentication method, characterized in that the random number generated by the host controller.

The method of claim 1,
The authentication code is generated by the first host, characterized in that the pipe authentication command (ADM_CREATE_PIPE) is transmitted to the host controller as a parameter.

The method of claim 1,
The authentication code is a pipe authentication method, characterized in that 1 or 2 bytes long.

The method of claim 1,
The additional host may include an embedded secure element host, an SD card secure element host, a fixed secure element, an external removable secure element, and an internal removable element of the terminal. A pipe authentication method comprising at least one of a secure element, a terminal software native application, a terminal Java applet, and a remote over the air application.

The method of claim 1,
And generating, by the host controller, an ADM_NOTIFY_PIPE_CREATE command including the authentication code as a parameter and transmitting the generated ADM_NOTIFY_PIPE_CREATE command to a second host which is a counterpart host of the corresponding pipe.

A pipe authentication method in a terminal having a UICC host, a terminal host, one or more additional hosts, and a host controller,
Generating, by a delete requesting host to delete a specific dynamic pipe, a pipe delete command (ADM_DELETE_PIPE) including an authentication code as a parameter and transmitting the same to a host controller;
An authentication step of the host controller performing authentication on the authentication code included in a pipe delete command parameter;
Generating, by the host controller, a response to the pipe delete command and transmitting the response to the delete request host;
Pipe authentication method comprising a.

The method of claim 7, wherein
And if the authentication for the authentication code is successful in the authentication step, the host controller further comprises generating and transmitting a pipe delete notification command (ADM_NOTIFY_PIPE_DELETE) to the target host.

The method of claim 7, wherein
And the target host is at least one of a destination host and a source host for the deletion target pipe.

The method of claim 7, wherein
The host controller stores and manages the authentication code obtained in the pipe creation process by matching the pipe identifier, and confirms whether the authentication code included in the ADM_DELETE_PIPE command parameter in the authentication step is a valid authentication code for the pipe identifier to be deleted. Characterized by a pipe authentication method.

The method of claim 7, wherein
And when the authentication of the authentication code fails, the host controller generates an ANY_E_PIPE_AUTH_FAIL, an error code indicating that the pipe deletion is rejected by the authentication code, and responds to the deletion request host.

The method of claim 7, wherein
The authentication code is a random number having a length of 1 or 2 bytes, characterized in that the pipe unique value.

9. The method of claim 8,
The ADM_DELETE_PIPE command parameter and the ADM_NOTIFY_PIPE_CREATE command parameter include a pipe identifier (P _ID ) for the corresponding pipe in addition to the authentication code.

In a multihost terminal comprising a UICC host, a terminal host, one or more additional hosts, and a host controller,
Generating, by a delete requesting host to delete a specific dynamic pipe, a pipe delete command (ADM_DELETE_PIPE) including an authentication code as a parameter and transmitting the same to a host controller;
Generating, by the host controller, a pipe delete notification command (ADM_NOTIFY_PIPE_DELETE) including the authentication code as a parameter to the host host;
The target host performing authentication on an authentication code included in an ADM_NOTIFY_PIPE_DELETE command;
Generating, by the target host, a response signal for an authentication result and transmitting the response signal to a host controller;
Pipe authentication method comprising a.

15. The method of claim 14,
The host controller further comprises the step of transmitting a response signal received from the target host to the delete request host as a response to the ADM_DELETE_PIPE command.

15. The method of claim 14,
And the target host is at least one of a destination host and a source host for the deletion target pipe.

15. The method of claim 14,
The response signal is an ANY_OK response without parameters if the pipe deletion is successful, and an ANY_E_PIPE_AUTH_FAIL response if an error occurs due to a mismatch in the authentication code.

A pipe authentication method in a terminal having a UICC host, a terminal host, one or more additional hosts, and a host controller,
Transmitting, by a first host of the hosts, a pipe creation command (ADM_CREATE_PIPE) for a specific dynamic pipe to a host controller;
The host controller generates a pipe creation notification command (ADM_NOTIFY_PIPE_CREATE) and transmits it to the second host that is the other host of the pipe.
And at least one parameter of the ADM_CREATE_PIPE command and the ADM_NOTIFY_PIPE_CREATE command includes an authentication code having a predetermined length corresponding to the generated pipe identifier.

A pipe authentication method in a terminal having a UICC host, a terminal host, one or more additional hosts, and a host controller, the host controller comprising:
Receiving a pipe delete command (ADM_DELETE_PIPE) including a pipe identifier of a pipe to be deleted as a parameter from a delete requesting host to delete a specific dynamic pipe;
Generating a response to the pipe delete command and transmitting the response to the delete request host;
Pipe authentication method, characterized in that the parameter of the pipe delete command further comprises an authentication code of a predetermined length.

A pipe authentication method in a terminal having a UICC host, a terminal host, one or more additional hosts, and a host controller, the host controller comprising:
After receiving the pipe delete command (ADM_DELETE_PIPE) from the delete request host that wants to delete a specific dynamic pipe, a pipe delete notification command (ADM_NOTIFY_PIPE_DELETE) is generated and sent to the target host. Doing;
Receiving a response to the ADM_NOTIFY_PIPE_DELETE command from the target host;
And an authentication code of a predetermined length is further included in a parameter of the ADM_NOTIFY_PIPE_DELETE command.

A host controller that works with UICC hosts, terminal hosts, and one or more additional hosts to create and generate notifications for specific dynamic pipes.
Receive a pipe creation command (ADM_CREATE_PIPE) for a specific dynamic pipe from the first host of the hosts, generates a response (ANY_OK) containing the authentication code for the generated pipe as a parameter, and transmits to the first host, A host that generates a pipe creation notification (ADM_NOTIFY_PIPE_CREATE) command and transmits it to a second host, which is a counterpart host of the corresponding pipe. controller.

Host controller that works with UICC host, terminal host, and one or more additional hosts to delete a specific dynamic pipe.
Receive a pipe delete command (ADM_DELETE_PIPE) including a pipe to be deleted identifier (ADM_DELETE_PIPE) from the delete request host to delete a specific dynamic pipe, and generates a response to the pipe delete command and transmits the response to the delete request host, A host controller comprising an authentication code of a predetermined length as a parameter of an ADM_DELETE_PIPE command.

A host controller that works with UICC hosts, terminal hosts, and one or more additional hosts to perform Delete notifications for specific dynamic pipes.
After receiving the pipe delete command (ADM_DELETE_PIPE) from the delete request host that wants to delete a specific dynamic pipe, a pipe delete notification command (ADM_NOTIFY_PIPE_DELETE) is generated and sent to the target host. And receiving a response to the ADM_NOTIFY_PIPE_DELETE command from the target host, wherein an authentication code having a predetermined length is included as a parameter of the ADM_NOTIFY_PIPE_DELETE command.