KR101583212B1 - Secured communication method for smart card applications - Google Patents

Abstract

The present invention relates to a method for forming a security communication channel between applications located in different security regions on a multi-applet smart card platform. Provided is the security communication method between smart card applications, comprising the steps of: enabling, via a system call, a first elementary applet to create a first elementary file within a first dedicated file and a second elementary applet to create a second elementary file within a second dedicated file, if information transfer from the first applet to the second applet, which are located in different security regions, is necessary; performing, via a communication-mediated applet for mediating communication between the first applet and the second applet, a reading operation for transfer-needed information written in the first elementary file and a writing operation for writing information read via the reading operation in the second elementary file; and allowing the second applet to perform a writing operation for the second elementary file wherein the transfer-needed information written.

Description

[0001] SECURED COMMUNICATION METHOD FOR SMART CARD APPLICATIONS [0002]

The present invention relates to a method for forming a secure communication channel between applets in a multi-applet smart card platform.

The multi-applet smart card platform manages a number of applets (i.e., applications or processes) produced by a plurality of different service vendors. Service vendors create applets to provide a variety of services to smart card users, and thus applets made on third parties are uploaded and run on the multi-applet smart card platform.

At this time, in the multi - applet smart card platform, it is required that the applets produced by each service vendor are securely separated completely. Therefore, in the multi-applet smart card platform, applets produced by one arbitrary service vendor and applets produced by another service vendor are executed in different security areas.

 However, depending on the service purpose of the applet, it may be necessary to communicate between applets belonging to different security areas. An example is a case where a mileage point accumulated by a membership applet produced by a first service vendor is used to deduct a ticket issuance fee from a ticket purchase applet produced by a second service vendor.

Therefore, when communication between applets belonging to different security areas is required, a method of forming a communication channel that can guarantee complete security between the two applets while maintaining the security required by the multi-applet smart card platform Is required.

Conventional IPC (Inter-process Communication) methods provided in an operating system include file sharing, memory sharing, pipelining, and message queue. However, such conventional IPC methods can not guarantee high security in an embedded operating system. For example, a resource sharing scheme such as file or memory sharing has a problem that malicious use can be made so that information can be leaked from a high security level applet to a low security level applet. In addition, there is a problem that the message queue method is strictly prohibited from being applied between two applets having different security areas.

The present invention provides a method for forming a secure communication channel between applets in a multi-applet smart card platform.

According to an aspect of the present invention, there is provided a method of forming a secure communication channel between applets in different security areas in a multi-applet smart card platform,

If it is necessary to transfer information from a first applet in a different security area to a second applet, the first applet is placed in a first elementary file (Dedicated file) through a system call, Causing the second applet to generate a second elementary file in a second dedicated file, the method comprising: generating an elementary file;

Performing a read operation on transfer necessary information recorded in the first element file through a communication parameter applet for mediating communication between the first applet and the second applet, Performing a write operation to write the read information to the second elementary file, wherein the communication parameter applet includes an area for a read operation and an area for a write operation, being-; And

And the second applet performs a read operation on the second elementary file in which the transfer necessary information is recorded.

In one embodiment, the first elementary file is generated as an initial content-free bean file, and after the first elementary file is generated, the first applet is transferred to the first elementary file And performing a write operation to record necessary information.

In one embodiment, the first applet and the second applet are vendor applets by different vendors that are not directly connected to each other for read / write, and the communication applet is a vendor applet that is different from the first and second applets It exists in another security zone.

In one embodiment, the communication mediation applet has a read right on the first dedicated file and the first elementary file, and has read rights on the second dedicated file, It can be an applet that is set to have write access to an elementary file.

In one embodiment, before the step of generating the first elementary file and the second elementary file, the first applet generates the first dedicated file and the second applet creates the first elementary file, 2 < / RTI >

Wherein the generating the first and second dedicated files comprises:

The first or second dated file is created under a specific dedicated file existing in the security area of the applet and the applet is added to the specific dedicated file that is a parent dedicated file And setting the right to have the read / write permission for the user.

In one embodiment, the first applet and the second applet are respectively granted read and write rights only in their own security areas, and the rights for the read operation and the rights for the write operation may be the same.

In one embodiment, the communication parameter applet comprises:

With respect to the read operation, a security tag defining a security level and an integrity tag defining an integrity level are provided for the security tag and the integrity tag for the read operation of the first applet The same,

With respect to a write operation, a security tag defining a security level and an integrity tag defining an integrity level are associated with a security tag and an integrity tag for the write operation of the second applet Can be the same.

According to the embodiment of the present invention, in a multi-applet smart card platform, security of a communication channel can be enhanced in forming a communication channel between applets executed in different security areas .

1 schematically illustrates a multi-applet smart card platform with a Java card as an example;
FIG. 2 is a conceptual diagram illustrating a method for forming a secure communication channel between two applets in different security areas in a multi-applet smart card platform. FIG.
3 is a flowchart of an embodiment for explaining a secure communication method between applets according to an embodiment of the present invention;

BRIEF DESCRIPTION OF THE DRAWINGS The present invention is capable of various modifications and various embodiments, and specific embodiments are illustrated in the drawings and described in detail in the detailed description. It is to be understood, however, that the invention is not to be limited to the specific embodiments, but includes all modifications, equivalents, and alternatives falling within the spirit and scope of the invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, the present invention will be described in detail with reference to the accompanying drawings. In addition, numerals (e.g., first, second, etc.) used in the description of the present invention are merely an identifier for distinguishing one component from another.

Also, in this specification, when an element is referred to as being "connected" or "connected" with another element, the element may be directly connected or directly connected to the other element, It should be understood that, unless an opposite description is present, it may be connected or connected via another element in the middle.

1 is a diagram schematically illustrating a multi-applet smart card platform using a Java card as an example. As an example of a multi-applet smart card platform, a Java card can be implemented as an open platform to provide users with applications (applets) that can provide various convenience. To this end, in the Java smart card platform, as shown in FIG. 1, a hardware layer in which a processor, a memory, an input / output module and the like are present, a card operating system on the hardware layer, A virtual machine (Virtual Machine) that supports the existence of a virtual machine, a Java Card API (Application Programming Interface) on a virtual machine, and a plurality of applets corresponding to application programs.

The multi-applet smart card platform to which the secure communication method between applets according to the embodiment of the present invention is applied can also be implemented based on the multi-applet smart card platform technology which is similar to the platform shown in FIG.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Before describing a method for secure communication between applets according to an embodiment of the present invention, basic concepts for understanding the present invention will be described.

As a method of forming a secure communication channel between applets, when applying a noninterfering security policy, a security tag may be utilized to define an access right. Here, access rights can be further subdivided into read access (i.e., allowing read operations) and write access (i.e., allowing write operations).

Referring to Bell and LaPadula (BLP) security model (DE Bell and L. LaPadula, "Secure Computer Systems: Mathematical Foundations and Model," Technical Report M74-244, MITER Corp., Bedford, Mass., 1973.) Is defined as having two security attributes as follows.

관계가 성립되어야 한다. 즉, 읽기 보안 레벨이 높은 객체에 관한 읽기 오퍼레이션은 불가하다(즉, no read-up).First, as a simple security property, if a subject having a security tag ST1 can read an object having the security tag ST2,

Relationship must be established. That is, read operations on objects with high read security level are not possible (ie no read-up).

관계가 성립되어야 한다. 즉, 쓰기 권한 레벨이 낮은 객체에 관한 쓰기 오퍼레이션은 불가하다(즉, no write-down).Secondly, in order for a subject having a security tag ST1 as a security * property (security * -property) to be able to correct an object having the security tag ST2,

Relationship must be established. That is, write operations on objects with low write permission levels are not allowed (ie no write-down).

When applying a noninterference security policy between applets, an integrity tag that defines the level of information integrity (integrity) may also be utilized. Two integrity attributes are defined as follows in the Biba Integrity Model (K. J. Biba, "Integrity Considerations for Secure Computer Systems," Technical Report ESD-TR-76-372, MITRE Corp., 1977.)

관계가 성립되어야 한다. 즉, 읽기 무결성 레벨이 낮은 객체에 관한 읽기 오퍼레이션은 불가하다(즉, no read-down). 정보의 순도가 떨어지는 객체에 관한 읽기를 허용하지 않는다는 의미이다.First, as a simple integrity propery, if a subject with an integrity tag IT1 can read an object with an integrity tag IT2,

Relationship must be established. That is, read operations on objects with low read integrity levels are not allowed (ie no read-down). This means that it does not allow reading about objects whose information is purity.

관계가 성립되어야 한다. 즉, 쓰기 권한 레벨이 높은 객체에 관한 쓰기 오퍼레이션은 불가하다(즉, no write-up). 정보의 순도가 높은 객체를 변경하는 것은 허용하지 않는다는 의미이다.Second, in order for a subject having an integrity tag IT1 as an integrity * -property to be able to modify an object having an integrity tag IT2,

Relationship must be established. That is, writing operations on objects with a high write permission level are not allowed (ie, no write-up). This means that it is not allowed to change objects with high purity information.

In the embodiment of the present invention, the security tag and the integrity tag are used in granting the read and write rights.

In an embodiment of the present invention, an intransitive noninterference security policy is applied in forming a secure communication channel. Hereinafter, this is simply referred to as INI security policy. To understand this, the transitive non-interference security policy (TNI security policy) is described first.

)에 있다고 할 수 있다. 반대로 후속적 영향을 주는 경우

로 간략히 표현한다. TNI 보안 정책에 의할 때, 만일

인 경우,

의 관계가 된다. 이와 달리,

인 경우라도,

관계에 있을 수 있다면, 이는 INI 보안 정책에 해당한다. 일 예로, A와 C의 중간에 다른 애플릿 B를 경유하는 매개 방식의 통신이 이루어지더라도, 애플릿 A가 애플릿 C로 직접 접속되는 것이 완전히 불허되는 것이 INI 보안 정책이 적용된 예이다.
When the action performed in the security area U does not have a subsequent influence on the security area V, the security area U and the security area V have a non-interference relationship (i.e.,

). Conversely, if there is a subsequent influence

. According to the TNI security policy,

Quot;

. Alternatively,

Even in this case,

If it can be in a relationship, this corresponds to the INI security policy. For example, an INI security policy is applied in which an applet A is completely prevented from being directly connected to an applet C even if an intermediary communication is made via the other applet B in the middle of A and C.

Now, in order to facilitate an understanding of embodiments of the present invention, smart card entities are described. An applet is an application program for performing specific functions on a smart card. All applets have a unique identifier (AID), and in the embodiment of the present invention, three basic data types (i.e., security level, integrity level, category) are given to each applet.

Accordingly, in the System state S, the applet can be modeled as follows. The modeling below uses the Z language. Hereinafter, all the modeling examples used in this specification are based on the Z language.

Here, sub_read_secClear_s stores (sets) the security access right for the read operation, and sub_read_intLevel_s stores (sets) the integrity level for the read operation. The security level and the integrity level for the write operation can also be confirmed in the same manner.

Accordingly, a vendor applet produced by a service vendor can be modeled as follows. In the embodiment of the present invention, two vendor applets (hereinafter referred to as applet A and applet C described in Figs. 2 and 3) that require secure communication are allowed to read and write only in their own security areas And the rights for the read operation and the rights for the write operation can be set to the same.

In addition, as a smart card entity, there are a Dedicated File (hereinafter abbreviated as DF) and an Elementary File (abbreviated below as EF).

DF corresponds to a directory in a general computer system, and EF is an entity corresponding to a file. DF and EF have their own identifiers (DF is DFID and EF is EFID). And DF and EF may be modeled as follows in an embodiment of the present invention.

In the embodiment of the present invention, the above EF is utilized as means for forming a secure communication channel between vendor applets.

Based on the above-described basic concepts, a secure communication method between applets according to an embodiment of the present invention will be described in detail with reference to FIG. 2 and FIG. FIG. 2 is a conceptual diagram for explaining a method of forming a secure communication channel between two applets in different security areas in a multi-applet smart card platform, FIG. 3 is a flowchart illustrating a method for secure communication between applets according to an embodiment of the present invention And FIG.

First, in Fig. 2, applet A and applet C are vendor applets, and applet B is a communication-mediated applet that mediates communication to implement secure communication between the two vendor applets. The security zone U to which applet A belongs and the security zone W to which applet C belongs are completely separated or isolated security zones. In addition, the vendor applet A is granted read and write privileges only within the security realm U, its read and write privileges are the same, and vendor applet C is granted read and write privileges only within the security realm. It is assumed that the rights are the same.

And the communication parameter applet B is an applet for implementing the INI security policy according to the embodiment of the present invention. To this end, the communication parameter applet B can be modeled as follows.

관계를 만족하도록 구현된다. 여기서,

는 논리적 NOT 연산자,

는 논리적 AND 연산자, 위 모델링에서

는 논리적 OR 연산자이다. 위 INI 애플릿의 모델링에서도 위 관계식을 만족하도록 읽기 및 쓰기 권한을 설정해놓고 있다.
In the embodiment of the present invention, the applet B as the INI applet is completely separated from the area for the read operation and the area for the write operation. That is, when expressing the tag for setting the authority for the read operation as RT and the tag for the write operation as WT, the communication parameter applet B

Relationship. here,

Is a logical NOT operator,

Is a logical AND operator, in the above modeling

Is a logical OR operator. In the modeling of the above INI applet, read and write permissions are set so as to satisfy the above relation.

If communication is required between two vendor applets belonging to different security areas and completely separated from each other as described above (refer to step S110 in FIG. 3), in the embodiment of the present invention, in step S120 to step S160 Through the process, secure communication is achieved. Hereinafter, the steps of FIG. 3 will be described in order.

Referring to step S120, when information transfer from the vendor applet A to the vendor applet C is required, the applet A generates DF1 and generates EF1 in the DF1. And applet C generates DF2 and creates EF2 in DF2. The generation of DF1, EF1, DF2, and EF2 may be indicated by a system call by the card operating system. At this stage, both EF1 and EF2 can be created as empty files with no content.

The generation of DF in this step S120 can be performed by the following method.

The system call transmitted for generating the DF includes the AID of the generating subject, the DFID of the target DF to be generated, and the DFID (hereinafter referred to as PDID) related to the parent DF, which is the directory to which the target DF will belong, as input parameters can do. Thus, a target DF is generated in the perforation DF.

관계를 갖도록 권한 설정된다. 이를 정의한 읽기 권한에 관한 모델링은 아래와 같다.
The precondition for DF generation is as follows. First, the creator must be a vendor applet, and the creator has read and write privileges on the Parent DF. To this end, firstly, with respect to the read right, when the security level and the integrity level of the corresponding vendor applet are defined as ST1 and IT1, and the security level and integrity level of the perforated DF are defined as ST0 and IT0,

A relationship is established. The modeling of the read authority that defines this is as follows.

About two validly write privileges, when levels of security and integrity level of the tea-vendor applet will be defined as ST1 and IT1, is set ST0 ⊇ ST1 ∧ IT1 ⊇ IT0 permission to have a relationship. The modeling of write privileges that define this is as follows.

The post condition for DF generation can be modeled as follows.

That is, when the target DF is created, it is stored under the pertain DF, and the newly generated target DF causes the security level and the integrity level to inherit the level of the vendor applet that is the subject of the generation.

In this step (S120), the generation of EF can be performed by the following method.

The system call transmitted for generating the EF includes the AID of the generating subject, the EFID of the target EF to be generated, and the DFID (i.e., PDID) related to the parent DF (i.e., the target DF Can be included as input parameters. Thus, a target EF is generated in the perforation DF.

The precondition for EF generation is as follows. The creator must be a vendor applet, and the creator has read and write privileges on the Parent DF. The post condition after EF generation is as follows. When the target EF is created, it is stored under the Parent DF, and the content of the first EF is set to zero. The security level and the integrity level of the newly generated target EF are made to take over the level of the vendor applet as the generating subject. The modeling of EF generation that defines it is as follows.

By the above-described method, the vendor applet A generates DF1 and generates EF1 in the DF1. And the vendor applet C can generate DF2 and generate EF2 in that DF2.

When EF1 is generated in DF1, in step S130 of FIG. 3, vendor applet A performs a write operation and writes information required to be transferred to vendor applet C to EF1 that was created as an empty file. These write operations can also be directed through system calls.

The system call for the write operation may include the AID of the write subject, the EFID of the target EF, the PDID of the pertinent DF to which the target EF belongs, and the input value for the write operation as input parameters. The preconditions for the write operation are as follows. The vendor applet that is the writer must have read access to the Perforce DF, and must also have write access to the target EF. This can be modeled as follows.

The postconditions after the write operation are as follows. The content of the EF is set to the input value passed by the system call, and its value is returned as the output parameter. This can be modeled as follows.

When the write operation is performed on the information to be transferred to the EF1 in the above manner, the applet B as the communication parameter applet performs the read operation on the EF1 in step S140 of FIG. 3, and updates the read information to the EF2 in step S150 update) operation.

At this time, modeling for a write operation has been described above, and modeling for a read operation will be described. The read operation is also indicated by the system call. The system call for the read operation may include the AID of the read subject, the EFID of the target EF, and the PDID of the pertinent DF to which the target EF belongs as input parameters. And, as a precondition to enable such a read operation, it is required that the read subject, the applet, has read rights on the perforated DF and target EF. The modeling is as follows.

The post-condition after the read operation is performed can be modeled as follows. That is, the applet returns the contents of the read EF as an output parameter.

In order to enable the execution of the read / write operations at steps S140 and S150 as described above, the communication parameter applet B has read permission for the DF1 and EF1 generated by the vendor applet A, and the DF2 generated by the vendor applet C , And can be set to have write permission for EF2. Modeling examples for this are shown below.

That is, the communication parameter applet B can separate the privileges related to the read operation and the privilege related to the write operation such that the INI security policy can be completely implemented.

The applet B has a security tag for defining the security level and an integrity tag for defining the integrity level with respect to the read operation and a security tag for the read operation of the vendor applet A, Can be set the same as the T-tag.

The applet B further includes a security tag for defining the security level and an integrity tag for defining the integrity level for the write operation of the vendor applet C, It can be set the same as the Integrity tag.

According to the preceding steps, when the information recorded in EF1 is updated to EF2, in S160 of FIG. 3, vendor applet C performs a read operation on EF2. Accordingly, secure communication can be performed between the two vendor applets completely separated from each other in security according to the INI security policy.

The security communication method between applets according to the embodiment of the present invention described above can be modeled as follows.

While the present invention has been particularly shown and described with reference to exemplary embodiments thereof, it will be understood by those of ordinary skill in the art that various changes in form and details may be made therein without departing from the spirit and scope of the invention as defined by the following claims And changes may be made without departing from the spirit and scope of the invention.

Claims (7)

A method of forming a secure communication channel between applets in different security zones in a multi-applet smart card platform,
If it is necessary to transfer information from a first applet in a different security area to a second applet, the first applet is placed in a first elementary file (Dedicated file) through a system call, Causing the second applet to generate a second elementary file in a second dedicated file, the method comprising: generating an elementary file;
Performing a read operation on transfer necessary information recorded in the first element file through a communication parameter applet for mediating communication between the first applet and the second applet, Performing a write operation to write the read information to the second elementary file, wherein the communication parameter applet includes an area for a read operation and an area for a write operation, being-; And
The second applet performing a read operation on the second elementary file in which the transfer necessary information is recorded
To-applet security communication method.
The method according to claim 1,
The first elementary file is generated as an empty file without an initial contents,
Further comprising: after the first elementary file is created, performing a write operation in which the first applet writes the transfer necessary information to the first elementary file, Secure communication method.
The method according to claim 1,
Wherein the first applet and the second applet are vendor applets by different vendors that are not directly connected to each other for reading and writing,
Wherein the communication parameter applet is in a different security area than the first and second applets.
The method of claim 3,
Wherein the communication mediation applet has a read right on the first dated file and the first elementary file and has a read right on the second dated file, A secure communication method between applets, which is an applet that is set to have write permission.
The method according to claim 1,
Wherein the step of creating the first element file and the second elementary file comprises the steps of the first applet creating the first dedicated file and the second applet creating the second dedicated file , ≪ / RTI >
Wherein the generating the first and second dedicated files comprises:
Generating the first and second dated files under a specific dedicated file existing in a security area of the applet,
And authorizing the applet to have read and write privileges on the specific dedicated file that is a parent dedicated file.
The method according to claim 1,
Wherein the first applet and the second applet have read and write privileges only in their own security areas and have the same privileges for a read operation and a write operation, respectively.
The method according to claim 6,
Wherein the communication-
With respect to the read operation, a security tag defining a security level and an integrity tag defining an integrity level are provided for the security tag and the integrity tag for the read operation of the first applet The same,
With respect to a write operation, a security tag defining a security level and an integrity tag defining an integrity level are associated with a security tag and an integrity tag for the write operation of the second applet Same, a secure communication method between applets.

Images