KR20090051823A - Method for managing m-commerce information using multiple security domain structure - Google Patents

Abstract

The present invention relates to a smart card for providing a financial information service through a layered security domain structure. Smart card providing a financial information service using a security domain according to the present invention is permanently mounted on the smart card and managed by an Issuer issuer security domain (ISD) ); First to Nth parent security domains (Parent Security Domain: PSD) which are changed or deleted according to a control signal of the issuer security domain; And first to Nth child security domains that are changed or deleted according to control signals of the parent security domain, wherein the child security domain manages an application for a specific financial service provided by a service provider. It is characterized in that the security domain. Accordingly, the present invention has the advantage of providing a smart card capable of providing a more diversified financial information service.

ISD, SD, GlobalPlatform, Smart Card, Security, Finance

Description

Method for Managing M-Commerce Information Using Multiple Security Domain Structure}

The present invention relates to a method of managing financial information in a smart card, and more particularly, to a financial system using a multi-security domain structure that can provide various and effective financial services using a hierarchical security domain structure in a smart card. The information management method.

As the use of smart cards is one of the basic specifications in the third generation mobile telecommunications market, each mobile carrier is actively researching the definition of its Universal Subscriber Identity Module (USIM) card specification and improving service using the USIM card.

Conventionally, the domestic mobile communication market has been mainstream in synchronous IS-95 network based on CDMA technology, but recently, Universal Mobile Telecommunication (UMTS) based on Wideband Code Division Multiple Access (WCDMA) method. System) service is being commercialized.

In particular, in recent years to meet the needs of various subscribers. Subscriber authentication cards are being developed with Java Card, one of the Open Platforms. Individual value-added services can be developed into each Java Card applet, providing flexibility in providing personalized value-added services according to subscribers' needs.

In other words, the USIM card has a large-capacity, multi-functional smart card function that can provide not only communication functions such as communication function and global roaming function, but also various additional service functions such as credit card, banking, securities transaction, royalties, and electronic payment. Can be.

Recently, researches on personal financial information management methods using security domains (SD) have been actively conducted to provide more secure smart card services.

The Security Domain can be viewed as a subject responsible for a kind of key management role that needs to be approached in terms of security. That is, the card issuer has a master key for issuing a card, and the master key can install or delete the applet on the smart card.

Therefore, using this key means an important role to determine the purpose of the card, so additional management is required.

The Security Domain, which is initially loaded on the card by the initial card issuer (Issuer), is called the Issuer Security Domain, and is managed by affiliates and application providers of the card issuer who develops or provides applications to manage separate keys. Security Domain is called Application Provider Security Domain or Supplementary Security Domain.

Of course, these are all applications, so they are basically applets on the Java Card platform, but in the following description, the Issuer Security Domain is referred to as ISD and the rest of the Security Domain is referred to as SD.

In the conventional method of managing financial information in a smart card, a service provider-for example, a mobile service provider-allocates an SD area to each financial institution using an ISD provided by the card issuer, and assigns the SD area to the assigned SD. Procedures for archiving the corresponding customer information were performed.

However, since the deletion and change of the information stored in the SD is possible only by the ISD, there are problems that the service provider has many limitations in providing various financial services.

An object of the present invention for solving the problems of the prior art as described above is to provide a financial information management method using a multiple SD structure in a smart card.

Another object of the present invention is to add a parent security domain (PSD) managed by an authorized organization to the existing SD structure to provide a variety of effective financial services to the service providers to provide a variety of effective financial services. It is to provide a financial information management method in a smart card.

In addition, an object of the present invention is to provide a GP-based smart card of a multi-SD structure to overcome the limitation of the financial information mounting caused by managing the SD only through the ISD.

Other objects of the present invention will be readily understood through the following description of the embodiments.

According to an embodiment of the present invention, a smart card for providing a financial information service using a layered security domain is disclosed.

Smart card providing a financial information service using a security domain (Security Domain) according to an embodiment of the present invention is permanently mounted on the smart card and issuing company security domain (Issuer) managed by a card issuer (Issuer) Security Domain (ISD); First to Nth parent security domains (Parent Security Domain: PSD) which are changed or deleted according to a control signal of the issuer security domain; And first to Nth child security domains that are changed or deleted according to control signals of the parent security domain, wherein the child security domain manages an application for a specific financial service provided by a service provider. It is characterized in that the security domain.

According to an embodiment of the present invention, a method of controlling a financial information service application using a layered security domain structure in a smart card connected to an external host is disclosed.

According to an embodiment of the present invention, a method for controlling a financial information service application in a smart card connected to an external host includes selecting a security domain for selecting a parent security domain according to a security domain selection command received from the external host. step; A mutual authentication step of authenticating the external host by using a key corresponding to the selected parental security domain; And an application installation step of receiving and activating an application file from the authenticated external host.

According to an embodiment of the present invention, a program comprising typed instructions for executing a method of controlling a financial information service application in a smart card connected to an external host and having a hierarchical security domain structure may be read by a recorded electronic device. A recording medium is disclosed.

According to an embodiment of the present invention, the recording medium includes a security domain selection step of selecting one of an issuer security domain and a parent security domain according to a security domain selection command received from the external host; A mutual authentication step of authenticating the external host by using a key corresponding to the selected security domain; A program comprising a typed command including an application installation step of receiving and activating an application file corresponding to the lower layer security domain of the selected security domain from the authenticated external host is recorded.

The present invention has an advantage of providing a method for controlling a financial information service application using a multiple SD structure in a smart card.

In addition, the present invention can provide a variety of effective financial services to the service provider by adding a Parent Security Domain (PSD) managed by an authorized organization to the existing SD structure to provide a variety of effective financial services for the service provider. There is an advantage of providing a financial information management method in a smart card.

In addition, the present invention is to provide a GP-based smart card having a multi-SD structure to overcome the limitation of the financial information mounting caused by managing the SD only through the ISD.

As the invention allows for various changes and numerous embodiments, particular embodiments will be illustrated in the drawings and described in detail in the written description. However, this is not intended to limit the present invention to specific embodiments, it should be understood to include all modifications, equivalents, and substitutes included in the spirit and scope of the present invention.

The terms first, second, etc. may be used to describe various components, but the components should not be limited by the terms. The terms are used only for the purpose of distinguishing one component from another. For example, without departing from the scope of the present invention, the first component may be referred to as the second component, and similarly, the second component may also be referred to as the first component.

The term and / or includes a combination of a plurality of related items or any item of a plurality of related items. The terminology used herein is for the purpose of describing particular example embodiments only and is not intended to be limiting of the present invention. Singular expressions include plural expressions unless the context clearly indicates otherwise.

In this application, the terms "comprising" or "mounted" and "mounted" are intended to indicate that there is a feature, number, step, action, component, part, or combination thereof described on the specification, one Or other features or numbers, steps, operations, components, parts or combinations thereof in any way should not be excluded in advance.

Unless defined otherwise, all terms used herein, including technical or scientific terms, have the same meaning as commonly understood by one of ordinary skill in the art. Terms such as those defined in the commonly used dictionaries should be construed as having meanings consistent with the meanings in the context of the related art, and shall not be construed in ideal or excessively formal meanings unless expressly defined in this application. Do not.

Other aspects, features, and advantages other than those described above will become apparent from the following drawings, claims and detailed description of the invention.

Hereinafter, a preferred embodiment of a financial information management method using a layered security domain structure according to the present invention and a smart card therefor will be described in detail with reference to the accompanying drawings.

1 is a hierarchical structure of a GP-based Java card according to the prior art.

As shown in FIG. 1, a Java card according to the prior art includes a Java Card Runtime Environment (JCRE) 110, a Card Manager (CM Manager 120), and a Global Platform Application Programming Interface (GP API) 130. , Java Card Application Programming Interface (140), Application Provider Security Domain Applet (150). It may include a Card Issuer Applet 160 and an Application Provider Applet 170.

Here, the card management unit 120 is composed of an Issuer Security Domain Applet (hereinafter referred to as "ISDA") and a global platform environment (glObalPlatform Environment: OPEN, 124).

In the following description, GlobalPlatform (hereinafter referred to as 'GP') will be described in detail to help the understanding of the present invention.

The GP was created in late 1999 as part of an effort by over 50 smart card affiliates to form a council to unify industry standards related to smart cards.

GP proposes all smart card-related industry standards, including smart cards themselves, smart card management systems (SCMS) and card terminals.

Especially in the open smart card environment, GP standard proposals occupy a very important place. The GP standard for smart cards is the GlobalPlatform Card Specification v2.1.1, released in March 2003. Java Card, which accommodated 2.0.1 version of GP, is currently mainstream in the smart card market, but recently, Java Card, which accepts the latest 2.1.1 version, has been introduced, especially in domestic banknotes and mobile carriers. GP is not essentially a smart card operating system (SCOS), or platform-oriented standard, so a smart card with GP is not necessarily a Java card.

This policy can be understood in terms of inducing GP application based on various SCOS. However, among the smart card platforms that accept GP, the most widely used platform is Java Card.

The GP card standard specifies support for Windows for Smart Card (WfSC) and provides API standards for it. However, note that the application example introduced as a GP-based smart card is almost Java-based. Recently, Visa and MasterCard, two major mountain ranges of credit card companies, have also joined the GP Council as full members, citing specific support for MULTOS, the card operating system of MasterCard, in the next GP Card standard. It is expected that the role of the Java GP card-later used as the term for a Java card with GP for convenience-could leap into the smart card market. Visa has strategically continued to support Java Card, and has developed OpenPlatform to facilitate multi-application operation, security and card management on its Java-based platform. Later, as Visa provided an open platform to the GP Council, the open platform was renamed GP.

The card management unit 120 performs a function of managing a Java card applet mounted on the java card and a function of managing a card life cycle for the Java card.

The ISDA 122 is an applet provided by the issuing card issuer, that is, "Issuer", which is recorded in a ROM (Read Only Memory) included in the Java Card hardware platform.

In general, a security domain is a subject that performs a specific key management function for providing a secure service on a smart card. That is, the card issuer has its own key and can load / install / delete the applet mounted on the smart card using the corresponding key. Therefore, the use of the key is an important means to determine the purpose of use of the smart card, it is natural that separate management is required.

In addition, a service provider who develops and provides an applet for providing a specific application service may have a key separate from a key owned by the card issuer for the applet.

In general, the security domain that issuer initially mounts on a card is called Issuer Security Domain and a separate key is installed by affiliates and application providers of card issuers who develop applications or provide services. The security domain that you manage is called the Application Provider Security Domain or Supplementary Security Domain.

The Application Provider Security Domain performs secure loading, installation, and deletion of pre-approved applets.

Accordingly, since the ISDA 122 and the APSD 124 are applications equipped with a management function for a key, they may provide basic security functions such as data encryption and digital signature.

The OPEN 124 is closely related to the security domain, and like the JCRE 110 which is a Java card environment, it manages various information existing in the Java card or selects and runs an application.

Therefore, the security domain applet can access the OPEN 124 through the GP API 130, and the OPEN 124 can manage the information while providing a repository for managing the characteristics or information for the applet. .

In addition, the OPEN 124 transmits a control command received from an external device, for example, a mobile terminal, to a corresponding applet (Command Dispatch), content management function (Content Management), security information management function (Security Management), or the like. Can be performed.

In the GP-based Java card, the ISDA 122 performs the overall card management function. For example, the ISDA 122 may perform a function of selecting an applet corresponding to a control command received from the outside and transferring the received control command to the selected applet.

Although not shown in FIG. 1, it should be noted that the GP-based Java card may further include a Controlling Authority Security Domain that performs verification of all loaded applets.

2 is a flowchart illustrating an applet installation process of a Java GP card.

In general, there are separate instructions for installing and running applets implemented through the GP API and general applets. Since these commands should not be used unnecessarily, they are basically processed through the ISD provided by the card issuer.

In the following description, the applet installation process in the Java GP card will be described in detail with reference to FIG. 2.

The external host 210 performs a selection procedure to select the ISD (S210). Here, the selection procedure (S210) is the step of transmitting a SELECT command defined in the APDU interface, for example, "SELECT Issure Security Domain"-to the Java GP card and the external host 210 is a response signal from the ISD 220- Receive a SELECT Response.

Thereafter, the external host 210 performs an optional authentication process (S220).

Here, the mutual authentication procedure (S220) is a process of performing communication in consideration of security between the external host 210 and the ISD (220). That is, the mutual authentication procedure (S220) is a process of mutual authentication by encrypting basic data transmitted by each other using a key provided by the ISD 220.

For this purpose, the concept of Secure Channel Protocol (hereinafter referred to as "SCP") is used, which is a definition of how to operate a key to maintain a session between the external host 210 and the ISD 220.

The mutual authentication procedure is performed using the INITIALIZE UPDATE and EXTERNAL AUTHENTICATE commands defined in the GP command standard.

If the mutual authentication procedure fails—that is, if the key provided by the ISD is not known—the external host 210 cannot arbitrarily install the applet on the smart card.

The external host 210 performs an INSTALL for load procedure for uploading the applet to the Java card (S230). At this time, basic information such as an application identifier (AID) of the Java card applet, as well as information on the SD managing the applet may be generated and stored in a predetermined recording area on the Java card.

When the INSTALL for load procedure is completed, the external host 210 performs a LOAD procedure for transmitting the contents of the CAP file of the Java Card applet to the ISD 220 through the LOAD command (S240). In general, since the data that can be sent through the APDU is limited, the data can be transmitted by using multiple LOAD commands.

When all the data is finally transmitted, the external host 210 performs an installation procedure for making the applet practically available through the INSTALL for install command (S250). Contains information to identify which SD the installed applet belongs to. Therefore, the applet can be managed according to the key of the corresponding SD. If necessary, the applet can be transferred to another SD.

However, in the applet installation process of the conventional Java GP card, the service provider cannot change or delete information on a specific SD mounted on the card through the external host 210 when the service provider does not receive the ISD key from the card issuer. There is a problem.

In other words, financial services may be provided by a card issuer. Accordingly, there may be many limitations in providing various effective M-Commerce services developed by service providers.

3 is a smart card authentication model according to an embodiment of the present invention.

As shown in FIG. 3, the smart card authentication model according to an embodiment of the present invention is an issuer security domain (ISD, 310) -parent security domain (PSD, 320) in a conventional ISD-SD structure. ) -Child security domain (CSD, 330) structure is characterized in that it is changed.

That is, the smart card authentication model according to the present invention is characterized in that the CSD 330 corresponds to a conventional SD, and the PSD 320 managed by an authorized institution such as a financial settlement agency is added between the ISD and the SD. do.

Here, the ISD 310 manages at least one PSD 320 and deletes a function of loading a new file into the PSD 320, a function of installing a loaded file, and a specific application managed by the PSD 320. To perform a function.

The PSD 320 manages at least one CSD 330 and may perform a function of loading a new CSD file, installing a loaded CSD file, and deleting a pre-installed CSD file.

In particular, it should be noted that, according to a preferred embodiment of the present invention, the external host 210 can delete or change the CSD 330 by selecting the PSD 320.

In addition, the PSD 320 preferably performs a function of managing at least one CSD 330 that provides a similar service, that is, corresponding to the same service area.

Although not shown in FIG. 3, the smart card authentication model according to the present invention may further include a Controlling Authority Security Domain that performs verification of all loaded applets. Be careful.

Although not shown in FIG. 3, the GP-based smart card authentication model according to the present invention may further include a Controlling Authority Security Domain that performs verification of all loaded applets. Note that you can.

Description of the OPEN 340, the Java Card Runtime Environment 350, the GP API 360, the JAVA Card API 370, the card issuer applet 380, and the application provider applet 390 shown in FIG. Will be replaced with the description of the corresponding component described in FIG.

4 is a diagram illustrating a security domain structure according to the present invention.

As shown in FIG. 4, the security domain managed by the card issuer is an ISD, and an external host may change or delete information corresponding to the first PSD and the Nth PSD managed by an authorized authority only through the ISD. .

At this time, it is preferable that the card issuer and the service provider classify the service area through negotiation and define a PSD corresponding to the service area.

For example, service areas may be divided into credit cards, electronic money, royalties, and traffic.

The key corresponding to the PSD is managed by an authorized authority, and the service provider can change or delete the desired CSD using the key assigned to the PSD.

5 is a diagram for describing a control relationship between security domains according to an embodiment of the present invention.

As shown in FIG. 5, the ISD 310 may perform a loading function and an installation function for mounting a new applet on the PSD 520 in a smart card.

In addition, the ISD 310 may delete a particular applet managed by the PSD 320.

The PSD 320 may change or delete information managed by a specific CSD 330.

In particular, it should be noted that the ISD 310 according to the preferred embodiment of the present invention cannot directly change or delete information of the CSD 330.

That is, since the ISD 510 can change or delete a specific CSD 330 only through the PSD 320 managed by an authorized agency, the card issuer cannot arbitrarily change or delete the applet without the service provider's consent.

6 is a flowchart illustrating an applet installation process using multiple security modes in a smart card according to an embodiment of the present invention.

In more detail, FIG. 6 is a flowchart illustrating a procedure for a service provider to mount a new applet on a smart card through the external host 610.

Here, it should be noted that the service provider knows the PSD key value provided by the authorized authority according to the agreement between the card issuer and the service provider.

The external host 610 selects the PSD by transmitting a predetermined security domain selection command (eg, "Select Parent Security Domain") to the smart card (S610).

The external host 610 performs a mutual authentication procedure with the selected PSD using a PSD key known in advance (S620).

If the external host 610 succeeds in mutual authentication with the selected PSD, the external host 610 performs an installation procedure for loading an applet to be mounted on the smart card (S630).

At this time, the OPEN 630 allocates an area for the CSD 330 corresponding to the applet file to be loaded according to a predetermined control signal received from the PSD 320 and updates related information in the allocated area (S635). .

If the installation procedure for loading is successful, the external host 610 transmits the applet to be mounted on the smart card to the PSD 320 using at least one APDU command message (S640).

Here, since one APDU command message may transmit a relatively small amount of data, the external host 610 may transmit a plurality of APDU command messages to load the entire applet file.

When data loading is completed, the OPEN 340 stores the loaded applet file in a predetermined recording area for the corresponding CSD 330 according to the control signal of the PSD 320 and performs verification of the stored applet file ( S645).

The external host 610 starts the applet installation procedure by sending a predetermined control signal (hereinafter, "application applet activation request signal") to the PSD 320 to activate the preloaded applet file when the data loading is completed. (S650)

When the PSD 320 receives the application applet activation request signal, the PSD 320 activates the applet, that is, the CSD 330 applet, stored and verified in step 645 (S655).

7 is a flowchart illustrating an applet installation process using multiple security modes in a smart card according to an embodiment of the present invention.

In more detail, FIG. 7 is a flowchart illustrating a procedure for the card issuer to mount a new applet on the smart card through the external host 610.

Here, it should be noted that the card issuer can change or delete the PSD information managed by the authorized authority by using the master key managed by the card issuer.

The external host 610 selects the ISD 310 by transmitting a predetermined security domain selection command (eg, “Select Issuer Security Domain”) to the smart card (S710).

The external host 610 performs a mutual authentication procedure with the selected ISD 310 using the master key (S720).

If the external host 610 succeeds in mutual authentication with the selected ISD 310, the external host 610 performs an installation procedure for loading an applet to be mounted on the smart card (S730).

At this time, the OPEN 340 allocates a new information storage area for the PSD 320 corresponding to the applet file to be loaded according to a predetermined control signal received from the ISD 310 and stores related information in the allocated area. (S735).

If the information storage area allocated for the PSD 320 already exists, the OPEN 340 may update the information recorded in the information storage area according to the control signal received from the ISD 310.

If the installation procedure for loading is successful, the external host 610 transmits the applet to be mounted on the smart card to the ISD 320 using at least one APDU command message (S740).

When the data loading is completed, the OPEN 340 stores the loaded applet file in a predetermined recording area for the PSD 320 according to the control signal of the ISD 310 and performs verification on the stored applet file ( S745).

When the data loading is completed, the external host 610 starts the applet installation procedure by sending a predetermined control signal (hereinafter, "application applet activation request signal") to the ISD 320 to activate the preloaded applet file. (S750).

When the ISD 310 receives the application applet activation request signal, the ISD 310 activates the applet stored in the operation 745 described above (ie, the PSD 320 applet) (S755).

Preferred embodiments of the present invention described above are disclosed for purposes of illustration, and those skilled in the art will be able to make various modifications, changes, and additions within the spirit and scope of the present invention. Additions should be considered to be within the scope of the following claims.

1 is a hierarchical structure of a GP-based Java card according to the prior art.

2 is a flowchart illustrating an applet installation process of a Java GP card.

3 is a smart card authentication model according to an embodiment of the present invention.

4 is a diagram for explaining a security domain structure according to the present invention;

5 is a diagram illustrating a control relationship between security domains according to an embodiment of the present invention.

6 is a flowchart illustrating an applet installation process using multiple security modes in a smart card according to an embodiment of the present invention.

7 is a flowchart illustrating an applet installation process using multiple security modes in a smart card according to an embodiment of the present invention.

* Key Drawing

310: Issuer Security Domain (ISD)

320: Parent Security Domain (PSD)

330: Child Security Domain (CSD)

340: Global Platform Environment (OPEN)

350: Java Card Runtime Environment

360: Global Platform API

380: Java Card API

Claims (16)

A smart card that provides a financial information service using a security domain, Issuer Security Domain (ISD) permanently mounted on the smart card and managed by a card issuer (Issuer); First to Nth parent security domains (Parent Security Domain: PSD) which are changed or deleted according to a control signal of the issuer security domain; And First to Nth child security domains that are changed or deleted according to the control signal of the parent security domain The smart card of claim 1, wherein the child security domain is a security domain for managing an application for a specific financial service provided by a service provider. The method of claim 1, The first through the N-th parent security domain is a security domain managed by a predetermined authority according to the agreement between the card issuer and the service provider. Smart card that provides financial information services. The method of claim 1, The parent security domain provides a financial information service using a multiple security domain structure, characterized in that for loading, installing and deleting an application corresponding to the child security domain without approval of the issuer security domain. The method of claim 1, The first to N-th parent security domains are classified according to service areas, and the service areas include at least one of credit card, electronic money, royalty, and traffic. Providing a smart card. The method of claim 1, The card issuer security domain provides a financial information service using a multi-security domain structure, characterized in that it does not load, install, and delete the application corresponding to the child security domain without approval of the parent security domain. The method of claim 1, The smart card includes a read only memory (ROM), wherein an application corresponding to the issuer security domain is stored in the ROM. The smart card provides a financial information service using a multiple security domain structure. The method of claim 1, The smart card provides a global platform composed of a global platform API and a global platform environment, but the parent security domain controls the child security domain through the global platform using a multiple security domain structure. Smart card that provides financial information services. The method of claim 1, The smart card provides a financial information service using a multiple security domain structure, characterized in that it further comprises an authorization control security domain that performs a verification function for all applications loaded from an external host. A method of controlling a financial information service application in a smart card connected to an external host, A security domain selection step of selecting a parent security domain according to a security domain selection command received from the external host; A mutual authentication step of authenticating the external host by using a key corresponding to the selected parental security domain; An application installation step of receiving and activating an application file from the authenticated external host; Application control method for a financial information service in a smart card comprising a. The method of claim 9, The application file received in the application installation step is an application control method for a financial information service in a smart card, characterized in that the application file corresponding to the child security domain. The method of claim 9, The application installation step Updating child security domain information corresponding to the application file; Receiving the application file through at least one Application Protocol Data Unit (APDU) command message; And Verifying the received application file Application control method for a financial information service in a smart card comprising a. The method of claim 9, The smart card further includes an issuer security domain that provides a function of changing and deleting the parent security domain. The method of claim 12, If the issuer security domain is selected by the external host, Authenticating the external hose using a master key corresponding to the issuer security domain; And Receiving and activating an application file corresponding to the parental security domain from the authenticated external host Application control method for a financial information service in a smart card further comprising. Claims [1] A recording medium readable by an electronic device on which a program comprising typed instructions for executing a method of controlling a financial information service application in a smart card having a hierarchical security domain structure connected to an external host is provided. A security domain selection step of selecting one of an issuer security domain and a parent security domain according to a security domain selection command received from the external host; A mutual authentication step of authenticating the external host by using a key corresponding to the selected security domain; And An application installation step of receiving and activating an application file corresponding to the lower layer security domain of the selected security domain from the authenticated external host The recording medium recorded by the program for executing the method of controlling the financial information service application in the smart card comprising a. The method of claim 14, And when the selected security domain is the parent security domain, the lower layer security domain is a child security domain. The recording medium recorded by a program for executing a method of controlling a financial information service application in a smart card. The method of claim 14, And when the selected security domain is the issuer security domain, the lower layer security domain is a parent security domain. The recording medium recorded by a program for executing a method of controlling a financial information service application in a smart card.

Images