JP2002073196A - Portable information processor provided with shared access managing function - Google Patents

Abstract

PROBLEM TO BE SOLVED: To enable the processor to be adaptive to the addition or deletion of application after card issue and to improve security in shared access. SOLUTION: In the portable information processor which can be mounted with plural re-writable applications and in which shared access is enabled between respective applications, each of applications has share managing information and when there is an access request from another application, the permission/non-permission of access and the addition/deletion of application are judged on the basis of the share managing information.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

[0001] 1. Field of the Invention [0002] The present invention relates to a portable information processing apparatus (for example, an IC card) capable of mounting a plurality of rewritable applications, and more particularly to management of access between applications.

[0002]

2. Description of the Related Art Access between applications on an IC card has a security problem, and is usually impossible by an OS or the like (firewall). However, IC cards with multiple applications use limited resources effectively, so it is necessary to allow limited access (shared access) in an environment managed by each other for the purpose of sharing functions and data. There is. Furthermore, since each application is added or deleted at an arbitrary timing, the management method needs to correspond to it. This sharing access will be described below. Here, the side requesting the sharing access is a client application,
The side that grants shared access and provides functions and information is called the server application.

Conventionally, when an application is mounted on an IC card, information (ID) of another application, which is predicted to require a shared access in advance, and a parameter for authentication (PIN: Personal Identifier).
An application number and the like are given to each application as data, and when the application wants to access another application, an ID of the application and an authentication parameter (PIN or the like) serving as an argument are passed to the target application. The server application requested to access compares the passed application ID and authentication parameter with data (a set of application ID and authentication parameter) known in advance, and determines access permission / non-permission based on a match / mismatch. . To add information (a set of an application ID and an authentication parameter) relating to another application, a procedure for creating a new application program and installing it again in the IC card is performed.

[0004]

SUMMARY OF THE INVENTION Such a conventional IC
Shared access management in a card has the following problems. Since the information of the application other than the user is determined at the time of issuing the card, the permission / rejection of the sharing access cannot be properly managed for the unexpected addition or deletion of the application. Conventionally, an application added later is dealt with as "other cases" so that the use of the application can be limited. If an existing application is re-inserted to support an application created later, the data corresponding to the application is also included, especially in the case of an IC card in which the application and data are managed integrally. May disappear. There is a possibility that an unauthorized application may acquire an unauthorized sharing access right, such as changing the authentication parameter (PIN) and trying access many times.

SUMMARY OF THE INVENTION The present invention has been made to solve the above-mentioned problems, and is capable of responding to addition or deletion of an application after a card is issued, and also monitors unauthorized sharing access and unauthorized access to sharing management information. The purpose is to increase security by blocking access to applications.

[0006]

SUMMARY OF THE INVENTION The present invention provides a portable information processing apparatus capable of mounting a plurality of rewritable applications and enabling shared access between the applications. It has management information, and when there is an access request from another application (client application), whether access is permitted or not is determined based on the shared management information. Further, the present invention is characterized in that the shared management information includes application management information, access management information, and authentication management information. Further, the present invention is characterized in that the application management information includes an access type for each ID for specifying a client application, information indicating a permission state for the ID and the access type, and the number of requests that failed in authentication for each access type. And Further, the present invention is characterized in that the access management information includes an authentication level for each access type and a return value returned to the accessed client application. Further, the present invention is characterized in that the authentication management information includes an access authentication condition and an addition / deletion authentication condition according to the authentication level. Further, the present invention is characterized in that the shared management information includes application management information and addition / deletion authentication condition management information. Further, according to the present invention, the application management information may include an access type for each ID for identifying a client application, information indicating a permission state for the ID and the access type, the number of requests that failed in authentication for each access type, and an access authentication condition. It is characterized by becoming. Further, the present invention is characterized in that the addition / deletion authentication condition management information includes an addition / deletion authentication condition and the number of requests. Further, the present invention is characterized in that when the number of requests exceeds a prescribed value, the permission state is closed and no further access is accepted. Further, according to the present invention, when there is a shared access from the client application, the server application may execute the function group of the access type in the permitted state on condition that the information indicating the permitted state is the permitted state and that the authentication is established. And / or passing a pointer to the object, wherein the client application calls a function on the server, the function performing the operation. Further, according to the present invention, when an application ID and an access type are added from the external terminal device to the application management information and a shared access is made from a client application that has acquired a function group of the server application and / or a pointer of the object, authentication is established. On the condition that the server application permits the permission state information of the application management information, and when the client application calls a function of the server application, the server application determines whether or not the access type of the function is the permission state by referring to the application management information. , The function executes a process on condition that it is in the permission state.

[0007]

Embodiments of the present invention will be described below with reference to the drawings, using an IC card as an example of a configurable information processing apparatus. (First Embodiment) FIG. 1 is a diagram for explaining sharing management information possessed by each application mounted on an IC card.
The shared management information is the application management information (FIG. 1)
(A)), access management information (FIG. 1 (b)), and authentication management information (FIG. 1 (c)). The application management information includes the ID (A
ID), access type (TYPE), permission status, and number of requests, and manages shared access from client applications. Each application individually owns, but an application that does not provide a shared access function may not be provided. In that case, the shared access request from any application will not be accepted.

[0008] The application ID (AID) is at least I for identifying a client application.
This is a unique number in the C card. Access type (T
YPE) specifies the data, functions, objects (units that combine data and functions) and the numbers that represent the sets of data and functions to be shared depending on the type of access given to the application, or directly addresses, pointers, and function names May be specified.

The permission state indicates a permission state of access to a certain application ID and an access type, and can at least indicate permission / non-permission / blockage. In addition, in order to increase the access speed, a state such as "permanent permission" which does not need to be authenticated once after authentication is successful or "temporary permission" in which the number of times and time limit are limited may be provided. In the closed state, as will be described later, authentication of shared access itself is not accepted. The number of requests counts the number of times that the authentication of the access type has failed, and the number of times that the authentication of the addition / deletion request to the application management information has failed. Note that items may be added so that the addition and deletion can be counted separately.

The access management information includes an access type, an authentication level, and a return value. The authentication level is a number indicating the level of authentication required for the shared access. The return value is a reference value for shared access to be returned to the client application. Function name, variable name, pointer to function, pointer to variable, reference to object, real address,
It is a value (the value itself to a variable) or the like, or a set thereof.

The authentication management information includes an authentication bell, an access authentication condition (PIN1), and an addition / deletion authentication condition (collation with a PIN2 previously provided for addition / deletion). If there is a request for a shared access at a certain authentication level, the access authentication conditions (PIN2
), Shared access is allowed.

[0012] The application management information can be added / deleted in pairs of an application name and an access type.
At this time, as shown in FIG. 1 (b), an authentication level corresponding to the access type is set, and an addition / deletion authentication condition corresponding to the authentication level is satisfied. As shown in c), a different PIN is prepared for each level.

Next, a procedure for adding / deleting application management information will be described. From the client application or terminal
The application ID to be added (deleted), the access type, and the authentication parameter (PIN) are passed to the server application. The server application searches for an authentication condition corresponding to the access type, and performs an authentication process (such as PIN verification). If the authentication succeeds, the application ID, the access type, and the permission status (permission) are added to the application management information held by the user. In order to prevent unauthorized applications and unauthorized access from outside, if authentication fails, the count of the number of requests is increased by one, and the permission status is "blocked" when a certain number of times is reached.
Thereafter, the application ID and the access type addition / deletion request are blocked. Unblocking cannot be performed or specific authentication is required.

Next, the procedure of the shared access management will be described. Directly from client application or OS
An access request is generated for data and processing through the server. The server application refers to the sharing management table and searches for a permission status flag from the set of the application ID and the access type. If the permission is granted and the authentication condition is satisfied, the access means to the client application is returned as a return value (data or function access). Reference address).

FIG. 2 is a view for explaining shared management information (stored in a memory area) possessed by each application. As shown, the application is my application I
D (AID) and information of the shared management table,
Application 0 has application management information, access management information, and authentication management information for AID1 and AID2. In the figure, a memory area in which data, functions, and the like originally owned by the application are stored is omitted. In the following, the applications of AID 0, 1, 2 are referred to as application 0, 1,
Let's call it 2.

FIG. 3 is a view for explaining an example of requesting shared access from a client application. In the example shown in the figure, the application 1 requests the application 0 for the access permission of the access type 1. Application 0 that is the server is AID and TY
An authentication PIN is searched from a set of PEs (access types),
When IN1 is 1234, it is confirmed that they match and that the access state is permission (flag = 1), the access permission is issued, and a reference to the shared data function is returned.

FIG. 4 is a diagram showing an example in which shared access fails. The state where the application 3 is requesting permission of the access type (TYPE) 2 from the application 0 is shown. The application 0 serving as a server does not issue a shared access permission because the set of AID3 and TYPE2 is not in the shared management table.

FIG. 5 is a diagram showing an example of adding an application to the shared management information. The application 3 adds an application to the shared management information for the application 0, and the application 3 sends AID = 3, TYPE = 2, and the corresponding authentication parameter (PIN2 = 8765) to the application 0 serving as a server. send. Application 0 is TYPE = 2
Level 2 PI required to add access rights
N = 8765 (previously held) and PIN2 from application 3 are compared, and since both match, AID3 and TYPE2 are added to the shared management information. As a result, as shown in FIG. 6, the application 3 is added to the shared management information.

FIG. 7 is a diagram showing a flow of processing for adding shared access and application management information. When a call (function call or communication) occurs from an external terminal or a client (step S1), it is determined whether the request is an access request (step S2). If the request is an access request, it is determined whether or not the AID and TYPE are included in the application management information (step S3). If the application management information includes AID TYPE, then authentication processing (whether or not the PINs match) is performed (step S4), and PI
If N matches, a reference (return value) corresponding to the access type is returned (step S5). In step S4,
If the PINs do not match, the request count of the application management information is added by 1 (step S6), and it is determined whether the request count has exceeded a prescribed value (step S7). Is set to 2, and the access of this application is blocked (step S8). If the request is not an access request in step S2, it is determined whether the request is an addition request to the application management information (step S9). If the request is an addition request, the authentication level is searched from the access type, and an additional authentication level 2 PIN is obtained (step S10). Next, it is determined whether the PINs match (step S1).
1) If they match, A is added to the application management information.
It is determined whether there is an ID and an access type (step S1).
2) If not, add it to the application management information and set the permission status flag to 1. If there is an AID access type in the application management information, it is determined whether or not it is blocked (step S13). If it is blocked, the process ends. If not, the permission status flag is set. Set to 1.

FIG. 8 is a processing flow for explaining the procedure of shared access management. The AID, the access type, and the permission status are added to the application management information from the external terminal or the client (step S21). When the client requests the shared access (step S22), whether the permission status is permitted and whether the PINs match. It is determined whether or not these are satisfied (step S23). If these are not satisfied, the access is rejected. If they are satisfied, the server returns a pointer to a function group of the access type permitted to the client (step S24). The client calls a function of the server (step S25), and the function (actually, an object) executes a process (step S26). At this time, since the pointer to the already permitted function has been given, the process is executed without any particular check. (Second Embodiment) In the first embodiment, the authentication conditions are different for each access type, and when the access state is enabled, the access is freely made when the pointer to the function is obtained. Although different PINs were prepared for each level, authentication conditions were set for the application ID and the access type, and different PINs were not prepared for each level, and all pointers were returned when accessed, An example in which the function itself refers to the permission state when each function is executed will be described below.

FIG. 9 is a diagram for explaining the shared management information, which is composed of application management information and addition / deletion authentication condition management information. The application management information includes an AID, an access type, a permission state, the number of requests, and an authentication condition (FIG. 9A). The addition / deletion authentication condition management information includes an authentication condition (PIN2) and the number of requests. The application management information can be added or deleted in units of a combination of the application name and the access type. In this case, the condition is that the addition / deletion authentication condition shown in FIG. 9B is satisfied.

A procedure for adding access management information in the second embodiment will be described. The terminal passes the addition / deletion authentication condition (PIN2) to the server application. If the authentication succeeds, proceed to the next step. To prevent unauthorized applications and unauthorized access from outside, if authentication fails, increase the count of the number of requests by one, and when it reaches a specific number of times, "block", and thereafter Block addition / deletion requests to the server application. Unblocking cannot be performed or requires specific authentication. The terminal sends the application ID, the access type, and the authentication parameter (PIN1) to be added to the server application. The server application adds an application ID, an access type, and an authentication condition (PIN1) to its own application management information.

Next, a procedure for deleting the application management information will be described. The terminal passes the addition / deletion authentication condition (PIN2) to the server application. If authentication succeeds, proceed to the next step. To prevent unauthorized applications and unauthorized access from outside, if authentication fails, increment the request counter by one. Block the addition / deletion request to the server application. Unblocking cannot be performed or requires specific authentication. The application ID, the access type, and the authentication parameter (PIN1) to be deleted from the terminal are passed to the server application. The server application searches for the application ID and the access type from its own application management information, and checks the authentication condition (PIN1). If the authentication is successful, the management information for the application ID and the access type is deleted.

Next, the procedure of the shared access management will be described. Directly from client application or OS
Requests shared access through the server application, and a reference pointer to each function (actually an object) is returned from the server application. The client application sends the AID and the access type authentication PIN as parameters through the reference pointer. The server (actually, the authentication function of the server) refers to the management table, searches for the authentication condition from the set of the application ID and the access type, and sets the permission flag if the authentication is successful, and sets the state to the permission state. The client calls each function shared from the server and passes the AID as a parameter. Each function of the called server refers to the management table and checks whether the permission flag corresponding to the AID and the access type (each function belongs to a predefined access type) is “permitted”. If the permission is granted, the process is executed.

FIG. 10 is a view for explaining the sharing management information possessed by the application.
2 and management information PIN2 = addition / deletion authentication condition
4321 is shown.

FIG. 11 is a diagram showing an example of requesting shared access from a client application. Application 1 accesses application 0 with access type 1
The application 0 serving as the server searches for the authentication PIN from the set of the AID and the access type.
At 34, it is confirmed that it is correct. Since the PIN1s match, the permission status flag is set to 1 for AID1 and TYPE1.
(FIG. 12).

FIG. 13 is a diagram showing an example in which shared access has failed. The application 1 requests the access permission of the access type 1 to the application 0, and the application 0 serving as the server has the AID1 and the PIN1 of the access type 1 of 1234, and the PIN1 presented by the application 1 is 4321. Authentication is not established and sharing access permission is not issued.

FIG. 14 is a diagram showing an example of adding an application to the shared management information. The application 3 sends the access type 2 and the corresponding authentication parameters PIN1 and PIN2 to the application 0 to the application 0. The authentication condition (PIN2) necessary to add the access right of application 0 is authenticated, and the P sent from application 3 is authenticated.
IN2 = 4321 is PIN2 of application 0
= 4321, so AID = 3, TYPE =
2. PIN1 = 9876 is added as shown in FIG.

FIG. 16 is a diagram showing a processing flow of the second embodiment.

When an external call is made (step S31), it is determined whether the request is a shared access authentication request (step S32). If the request is a shared access authentication request, it is determined whether the AID and the access type are included in the application management information (step S33). If there is, it is determined whether or not it is blocked (step S
34) If not blocked, it is determined whether the PINs match (step S35). If the PIN matches,
An authentication flag corresponding to the AID and the access type is set (step S36). In step S35, the PIN
If they do not match, the number of requests for application management information is increased by 1 (step S37), and it is then determined whether the number of requests exceeds a prescribed value (step S38). AI
D and the flag of the access type are set to 2 and closed (step S39). If the request is not a request for shared access authentication in step S32, it is determined whether the request is a call for a shared function (step S40). If the request is a function call request, the access type of the called function is set (step S41), and it is determined whether or not the application management information includes the AID and the access type (step S42). It is determined whether it is not blocked (step S43). If not closed, it is determined whether or not the authentication flag is set (step S44), and processing of a function called that the authentication flag is set is executed (step S45).

FIG. 17 is a processing flow chart showing the procedure of shared access management in the second embodiment. The client application in which the AID and the access type are added to the application management information from the external terminal (step S51) can obtain the pointer of the function group of the server application (step S52). When the client application makes a request for shared access (step S53), the server application determines whether the PINs match (step S54). If the PINs match, the permission state of the application management information is set to “permitted”.
(Step S55), and if they do not match, it is rejected. Next, when the client application calls the function of the server application (step S5)
6), it is determined by referring to the application management information whether the access type of this function is in the permitted state (step S57). If the function is in the permitted state, the function executes the process. Becomes

[0032]

As described above, according to the present invention, in the shared access management in a portable information processing apparatus capable of mounting a plurality of applications, it is possible to correctly correct addition or deletion of an application that was not initially supposed. Permission / non-permission of the access type can be managed, and functions and data can be made accessible / impossible. Also,
It is possible to prevent sharing access from an unauthorized application and prevent unauthorized acquisition of a sharing access right.

[Brief description of the drawings]

FIG. 1 is a diagram illustrating shared management information possessed by each application mounted on an IC card.

FIG. 2 is a diagram illustrating shared management information possessed by each application.

FIG. 3 is a diagram illustrating an example of requesting shared access from a client application.

FIG. 4 is a diagram illustrating an example in which shared access fails.

FIG. 5 is a diagram illustrating an example of adding an application to shared management information.

FIG. 6 is a diagram illustrating an example in which an application is added to the shared management information.

FIG. 7 is a diagram showing a shared access and application management information addition processing flow.

FIG. 8 is a process flowchart illustrating a procedure of shared access management.

FIG. 9 is a diagram illustrating shared management information.

FIG. 10 is a diagram illustrating shared management information possessed by an application.

FIG. 11 is a diagram illustrating an example of requesting shared access from a client application.

FIG. 12 is a diagram illustrating an example in which an authenticated flag is set.

FIG. 13 is a diagram illustrating an example in which shared access has failed.

FIG. 14 is a diagram illustrating an example of adding an application to shared management information.

FIG. 15 is a diagram illustrating an example in which an application is added to the shared management information.

FIG. 16 is a diagram showing a processing flow of the second embodiment.

FIG. 17 is a diagram illustrating a processing flow of a procedure of shared access management according to the second embodiment;

[Explanation of symbols]

AID: Application ID, TYPE: Access type.

Claims (11)

[Claims] In a portable information processing apparatus capable of mounting a plurality of rewritable applications and enabling shared access between the applications, each application (server application) has sharing management information, A portable information processing apparatus having a shared access management function, characterized in that when there is an access request from an application (client application), permission / non-permission of access is determined based on the shared management information. 2. The portable information processing apparatus according to claim 1, wherein the shared management information includes application management information, access management information, and authentication management information. 3. The application management information includes an access type for each ID for identifying a client application, information indicating a permission state for the ID and the access type, and the number of requests for which authentication failed for each access type. 3. The portable information processing apparatus according to claim 2, wherein 4. The apparatus according to claim 2, wherein the access management information includes an authentication level for each access type and a return value returned to the accessed client application.
The portable information processing apparatus according to the above. 5. The portable information processing apparatus according to claim 2, wherein the authentication management information includes an access authentication condition and an addition / deletion authentication condition according to an authentication level. 6. The portable information processing apparatus according to claim 1, wherein the shared management information includes application management information and additional / deleted authentication condition management information. 7. The application management information includes: an access type for each ID for specifying a client application; information indicating a permission state for the ID and the access type; the number of requests that failed in authentication for each access type; and access authentication conditions. 7. The portable information processing apparatus according to claim 6, wherein: 8. The portable information processing apparatus according to claim 6, wherein the additional deletion authentication condition management information includes an additional deletion authentication condition and a request count. 9. The portable information processing apparatus according to claim 3, wherein when the number of requests exceeds a prescribed value, the permission state is closed and no further access is accepted. 10. When there is a shared access from a client application, a condition indicating that the information indicating the permission state is the permission state and the authentication is established, the server application executes the function group of the access type in the permission state and Passing the object pointer, the client application calls a server function,
4. The portable information processing apparatus according to claim 3, wherein the function executes a process. 11. The authentication is established when an application ID and an access type are added from the external terminal device to the application management information, and there is a shared access from a client application that has acquired a function group of a server application and / or a pointer to an object. On the condition that the server application permits the permission state information of the application management information, and when the client application calls a function of the server application, it determines whether or not the access type of the function is the permission state by referring to the application management information, 8. The portable information processing apparatus according to claim 7, wherein the function executes a process on condition that the function is in a permission state.