EP1240570A2

EP1240570A2 - Capability-based access control for applications in particular co-operating applications in a chip card

Info

Publication number: EP1240570A2
Application number: EP00990048A
Authority: EP
Inventors: Gilles Grimaud; Daniel Hagimont; Jean-Jacques Vandewalle
Original assignee: Gemplus Card International SA; Gemplus SA
Current assignee: Thales DIS France SA
Priority date: 1999-12-10
Filing date: 2000-12-08
Publication date: 2002-09-18
Also published as: US7490333B2; FR2802319B1; FR2802319A1; WO2001042887A3; WO2001042887A2; AU2685701A; US20030065982A1

Abstract

The invention concerns an application programmer no longer responsible for managing access rights, the application code being independent of the protection in the chip card. The capability-based access control consists, when an application (Aa), for example in a docking station, is given access to an object (Ob1) pertaining to the other application (Ab) in a chip card (CP), in creating two capabilities (Fa(Ob1), Fb(Ob1)) respectively in the applications, as objects, to protect all subsequent accesses to the object by filtering them through the two capabilities. On accessing (E1) an object (Ob1) pertaining to an application (Ab), if a second object (Ob2) pertaining to the other application (Ab) is passed on to the latter, two other capabilities (Fa(Ob2, Fb(Ob2)) are added (E2) in the applications to protect access to the second object.

Description

Access control by capacity for particularly cooperative applications in a smart card

The invention relates to smart cards, also called microcontroller card or integrated circuit cards, and more generally programmable open data processing means can be charged ^'for applications written in high level programming language. An open chip card, as presented for example in document WO 98/19237, manages several applications, for example a customer account for a store, a bank account or an electronic purse. Some applications loaded into the card sometimes cooperate, for example, to pay for a purchase from the store, and / or also cooperate with applications running outside the card.

Application cooperation requires the establishment of access right rules, since applications do not necessarily trust each other. For example, the customer account managed by the store must not take over data managed by the electronic purse.

In an IT environment, access control management consists in associating access rights to objects managed in the environment for each user, and in verifying that these access rights are respected. The management of access control is shown diagrammatically in FIG. 1 by the management of an access matrix MA. The rows of the matrix MA correspond to the rights of J objects 01 to OJ and the columns of this matrix correspond to the rights of I users Ul to UI. A box in the matrix at the intersection of a line and of a column gives access rights Dij of a user Ui to an object Oj, with l = i = I el = j = J, for example a right to read, write or execute a file. In practice, the MA matrix is partially empty, users often having no rights on many objects, and presents one of the two configurations consisting of a grouping of access rights per line and a grouping of rights of access by column.

The grouping by line amounts to associating with each object Oj, an access list indicating the access rights Dlj to Dij on the object respectively for the users UI to UI. In a management by access lists respectively associated with objects, only the owner of an object Oj modifies the access list Dlj to Dij associated with the object; such a modification is made explicitly by calling an operation on the object requesting the modification of its access list. The protection schemes based on access lists are then qualified as static, the modification of access rights being complex and users tending to oversize the access rights of their objects. This goes against the principle of least privilege (in English: need to know principle) according to which access rights are granted only as and when required.

The grouping by column associates with each user Ui a list of capacities indicating the access rights Dil to Dij of the user respectively for the objects over which the user has a right. Each item (Oj, Dij) in the list is called an ability. A capacity is a descriptor containing the identification of an object Oj as well as a definition of access rights Dij on this object. In management by capacities, a user has a list of capacities, a capacity which can be compared to a token giving the right to perform an operation on the object. A capacity identifies an object, but also includes a definition of access rights on the object. A capacity can then be used as an object identifier that an application can pass as a parameter to another application, following a conventional programming mode, with the limitation that this identifier does not authorize all operations on the object. designated.

It follows that the modification of access rights is more natural with capabilities: granting an application or a user access rights to an object amounts to passing it the parameter of an operation the identity of the object in the form of a capacity.

Capacities provide greater dynamics in the management of access control, access rights can be easily exchanged between users of the environment. However, when a user or an application must pass a capacity on an object as a parameter, the user or the application must first decide on the rights to be transferred with the capacity. An operation generally makes it possible to reduce the rights associated with the capacity if necessary, before passing it as a parameter.

In the prior art, hardware implementations and software implementations are known with capacities comparable to tokens. The first material achievements were based on specialized machines in the 70s. The addressing mechanism of these machines directly implanted the concept of capacity: a register _Λ ,, _” „ _o , 01/42887 4

address used to address an object also contained the access rights to the object (the register containing the token). The values of these registers could be exchanged between users, but could not be forged, the material not allowing it. Software developments, more recent in the 1980s, relied on encryption for capacity protection. A capacity was signed and could only be created

10 by the owner of the object.

Thus, document US 5781633 illustrates an earlier technique allowing filtering, by means of capacities, of exchanges of object references between different processes. Cryptographic processes

15 are used to mainly guarantee the integrity of the references exchanged. Cooperation between processes is achieved by transmitting a reduced view of an object from one process to a second process. The filter thus created is implemented

20 within the access requesting process. In a context of the “mutually suspicious process” type, the process disclosed by the document is ineffective. In fact, the access requester process can modify the filter sent to it as it pleases and access

25 thus to methods which are however prohibited to it.

The invention relates more particularly to an access control mechanism based on a scheme of

30 capacity protection to manage cooperation between applications in the context of a smart card. Indeed, the context of the smart card is characterized by cooperation between applications not provided in advance. It is therefore

35 difficult to satisfy a protection scheme like the access lists where the access rights are most often pre-established. The dynamics of the capacity-based scheme is a real need.

In current solutions in the context of the smart card, a programmer must manage capacities "by hand" in the application code, which leads to a complexity of programming protected applications.

The invention implements a capacity model in the context of the smart card to pursue two objectives:

- Preserve the simplicity of programming the JAVA language in the context of the JAVA Card. To do this, the invention aims to make the application code independent of protection. The specification of the protection policy, that is to say of the capacity management, is separate from the application code.

Allow cooperation between applications in the card, but also between applications in the card and applications outside the card. This requires considering the operating system in the card as a secure environment and the outside of the card as a hostile environment. The achievement of these two objectives by the invention provides great simplicity in programming access control, which also reduces the cost of code development and maintenance, as well as the risks of protection programming errors.

The first objective leads to separating the development of the application and the management of access rights, thus simplifying the complexity. The application programmer programs applications without worrying about managing access rights. This is specified separately in a simple and very intuitive formalism.

For the second objective, the invention offers a model for managing uniform access rights while the underlying constraints are very different when one is in the card or outside the card.

The two objectives respond to the same motivation consisting in masking the complexities inherent in protection and the card, and in simplifying the programming of protected cooperating applications.

To achieve these objectives, the invention provides a process for generating applications, characterized in that it comprises:

- a step of developing an application comprising an object or several objects, without restriction of access; a step of defining rules for access rights to the object or objects, included within the application, from a second application or from several other applications;

a step of transforming the application comprising the object or objects by adding to said application, means for filtering access to said object or to said objects in order to implement an access control method ensuring the cooperation of the applications; - a step of implementing the transformed application within a data processing means.

According to a first embodiment, the data processing means is included in a smart card. According to a second embodiment, the data processing means is included in a docking station for the smart card.

In addition, according to the invention, the access control method between two applications each cooperating by means of capacities on objects belonging to the other application, the applications cooperating through at least one operating system, is characterized by the next step: when one of the applications, called the access requester application, is given access to an object belonging to the other application, called the access provider application; create two capacities respectively in said requesting and access provider applications, as objects; the capacity created in the access provider application to limit access to said object and; the capacity created in the access requesting application to associate the access requesting application with the capacity created in the access provider application.

According to another aspect of the invention, when accessing an object belonging to one of the applications, if a second object belonging to one of the applications is passed to this application, the method comprises the step of add two other capabilities respectively in the applications to protect access to the second object. In practice, the ability to access the second object belonging to one of the applications is passed as a parameter or as a result to the other application.

According to a first embodiment, the applications can be implemented in a common data processing means, for example in a smart card or a terminal. In the case of a smart card, the Verifications of the code loaded in the smart card ensure that a capacity cannot be created by a pirate programmer.

According to a second embodiment, the applications are implemented in two remote data processing means exchanging access messages to remote objects. The step of adding two other capacities can then preferably comprise the storage of a secret word in the two other capacities, passed to them by the two capacities previously created in the stage of creating, in order to validate the access to the second object.

The data processing means can be included respectively in a smart card and a smart card docking station, or in two separate smart cards, or in two controllers of a smart card or a terminal .

Other characteristics and advantages of the present invention will appear more clearly on reading the following description of several preferred embodiments of the invention with reference to the corresponding appended drawings in which: FIG. 1 shows a matrix of access rights already commented on ;

- Figure 2 is a block diagram showing interfaces between a bank application and a client application;

- Figure 3 is a block diagram showing interfaces of two cooperating applications according to the invention; FIG. 4 is a block diagram showing the installation of filter objects between two cooperating applications at an initial stage of the method according to the invention; - Figure 5 is a block diagram showing the addition of two filters when called by an application of the method on a first object in another application, according to a first embodiment of the method of one invention; and

- Figure 6 is a block diagram similar to Figure 5, showing the addition of two filters when calling by an application in a method call station on a first object in another application in a card chip, according to a second embodiment of the invention.

The general concept underlying the invention is capacity management, that is to say the management of basic access rights, separately from an application.

When two applications cooperate, this cooperation follows a pre-established cooperation protocol. This cooperation protocol generally takes the form of a common interface allowing applications to call each other. More precisely, in the context of the JAVA Card, each application which wishes to call another application does so by using a JAVA interface which is the one which is supposed to provide the called application.

With reference to the example illustrated in FIG. 2, a BA bank, that is to say a bank application in a server, manages accounts for clients. When a CL client connects to the bank through an ATM OG object, the bank returns a Ref reference to him on his OC Bank Account object so that he can read the status of his account. Each bank and client application knows the IG and IC cooperation interfaces which are those of the ATM and Account objects. The GU counter object interface allows the customer to connect to the bank by giving their name and an access code, such as a Personal Identity Number (PIN), and to return the Ref reference to the OC Account object. The interface of the IC Account object provides two methods respectively for reading and writing the balance of the bank account, the syntax used being that of the JAVA language.

The protection requirements in this example are presented below. The bank has all rights to its own objects. But it is unthinkable that the bank should grant all rights to its customers. A customer can read the balance of his bank account, but must not be allowed to write arbitrarily the balance of his account. This is why, in a capacity protection scheme, the bank returns as a result of the connection operation a capacity corresponding to the reference on the Account object, but with rights that only allow the call of the account reading operation. The bank which has all the rights to its own objects, including the Account object, creates a capacity authorizing only reading on this object and returns this capacity to its client. Since the first objective of the invention is to separate the definition of the protection policy and the application code, the invention aims more particularly to provide rules for the exchange of capacity between the applications at the level of interfaces used to cooperate.

In the example shown in Figure 2, the provision of access control by programming is located at the interface of the OG Counter window object of the BA bank. According to a first aspect of the invention, this programming tool specifies in the interfaces used the capacity that must be transferred during a parameter transmission between applications. We obtain a "protected" interface called view (view in English) which takes the following form in JAVA language, the word "String" designating a character string object:

view counter {

Carpte_client connexion (String nom, String pin-code);

} view Comp te _c link {

Balance read ();

NOT void write (Balance s);

}

The specification of these two views indicates that the BA bank lets out only capacities allowing to read the account balance. The code of the bank application and the client application thus remains completely independent of protection.

More generally, the programming tool allows each of the applications, the bank application and the client application according to the previous example, to define its own protection rules. When an AA application has a capacity towards an OB object of an AB application as shown in FIG. 3, the capacity includes the protection rules defined by the AA application and grouped in a protected interface "view" IA and the rules protection defined by the AB application and grouped in a protected "view" IB interface. The IB view has two roles: limiting the methods that the AA application can call on the OB object and associating the view chosen by the AB application with the inbound and outbound capabilities of the AB application when the OB object is called. The AI view only fulfills the second role for the capacities entering and leaving the AA application. Thus, for each capacity exchanged as a parameter of the call from the AA application to the AB application, or from the AB application to the AA application, the view IA associates a view IA 'with this capacity and the view IB associates an IB 'view with this ability.

Another aspect of the invention is the integration of the programming tool in the context of the smart card. In the context of an open chip card, applications are loaded into the card. These applications, called internal applications, interact with each other, but also with applications, called external applications, executed in a docking station, such as a bank terminal, a point of sale or a mobile radiotelephone terminal, in which the card is inserted. This implies that capacities are exchanged between internal applications and external applications. The programming tool associated with the invention is implemented by considering the following parts of this context related to the card and to the docking station:

The JAVA Card smart card is a protected environment in the sense that the JAVA code loaded in the smart card is verified before it is actually loaded. This verification aims to ensure that the code to be loaded has certain properties of the JAVA code, mainly related to security. The JAVA language does not allow direct manipulation of addresses and therefore arbitrarily overwrite memory, which provides a certain degree of security when different programs are hosted in the same JAVA virtual machine. The implementation of the protection scheme of the invention takes account of this internal context of the card for the implantation of the capacities in the card.

- The docking station in which the card is inserted is not necessarily a secure environment. Indeed, the card can be inserted into any docking station, and the docking station can very well send fabricated data to fool the card. When they are propagated outside the card, the capacities are according to the invention protected by secrets which make it possible to verify the validity of the capacities used by applications external to the card.

The invention thus relates to a programming tool for programming the management of access rights between cooperating applications running in the smart card or in the docking station. The definition of the rules for managing access rights is separated from the application code, which gives greater clarity. Integration in the context of the JAVA Card smart card requires managing the capacities inside and outside the smart card differently.

The programming tool associated with the invention specifies the rules for protecting an application separately from the code of the application.

It is assumed that a first application Aa written in JAVA language cooperates with a second application Ab also written in JAVA language through a cooperation interface lab located in a single data processing means, by example a smart card with a specific operating system and the JAVA virtual machine:

interface lab {void methl (Il pi); 12 meth2 (); void meth3 ();

}

The lab interface contains the definitions of three methods methl, meth2 and meth3. The methl method takes in parameter pi a reference to an object of type interface II and does not return any result. The meth2 method takes no parameters and returns a result of type interface 12. The meth3 method takes no parameters and returns no results.

Each application then specifies protection interfaces called views, for example the following views Iab_V, I1_V1 and I2_V2:

view Iab_V {void methl (I1_V1 pi); I2_V2 meth2 (); NOT void meth3 ();

}

When the Aa application has a capacity on an object belonging to the Ab application, the Aa and Ab applications have the possibility of specifying the protection to be associated with this capacity by associating a view with this capacity.

The Iab_V view indicates that only the methl and meth2 methods are allowed. It also indicates that if the methl method is called, then _{1 g}

the application, which can be a calling application or a called application, protects itself by associating with the capacity passed in parameter the view I1_V1. Finally, it indicates that if the method meth2 is called, then the application protects itself by associating with the capacity passed in result the view I2_V2.

When the application Aa has a capacity towards an object of the application Ab, the view that the application Aa associates with this capacity allows the application Aa to control the capacities which enter into and leave it, that is, to associate a view with these capabilities. Conversely, the view that the Ab application associates with this capacity allows the Ab application to control the capacities which enter and leave it, but also to limit the methods which can be called on the object of the application Ab.

In general, the first export of an access capacity from the application Ab to the other application Aa and the first import of this capacity by the other application Aa, go through a name server. The Ab application exports the access capacity by associating it with a symbolic name, such as a character string, and the Aa application imports the exported access capacity by interrogating the name server with the symbolic name. The Ab application exports the capacity by explicitly specifying the view that the Ab application associates with it. The Aa application imports the exported capacity by explicitly specifying the view that the Aa application associates with it. For the Aa application as for the Ab application, the specified view indicates for all the exchanges of capacity as a parameter arising from this first exchange, the views that will be associated with these capacities passed as parameters.

As a result, except for this first exchange of access capacity messages, the protection policy for each application according to the invention, that is to say the manner of exchanging capacities, is specified at the interface level. and is not embedded in the application code.

The implementation of the protection policy according to the invention is based on the concept of filter objects, "illustrating" capacity objects (meaning aptitudes or faculties, or in English "capabilities"), which are inserted between the applications Aa and Ab . For each view defined by an application, a filter class is generated and an instance of this class is inserted at runtime in the access chain to an object whose capacity is exported. As shown in FIG. 4, if at an initial step E0 access to an object Ob belonging to the application Ab is given to the application Aa, the view of the application Aa for the capacity of this access is established by a filter Fa and the view of the application Ab for this capacity is implemented by a filter Fb.

A filter class defines all the methods declared in the view that the filter implements. Its role is to retransmit the method call to its successor in the access chain to the object. According to the example shown in FIG. 4, the filter Fa retransmits the call to the filter Fb and the filter Fb to the object Ob.

On the other hand, a filter class implements the protection policy defined by the view from which it is generated: the Fb filter does not leave pass only the methods authorized by the Ab application view; and the filters Fa and Fb also implant the association of the views with the capacities passed as a parameter. According to the example of views above, the Iab_V view indicates the association of the I1_V1 view with the pi parameter of the methl method. The association of the view with the capacity is implemented by inserting into the access chain to the object passed in parameter a filter object corresponding to the view. With reference to FIG. 5, for two applications Aa and Ab located in a smart card CP, the application Aa has, at the initial step E0, a capacity towards the object Ob of the application Ab, and as in the figure 4, subsequent accesses to the object Ob are protected by the filter Fa (Ob) of the application Aa and by the filter Fb (Ob) of the application Ab. At a first step El, during the call by the Aa application of the methl method on the Ob object belonging to the Ab application, that is to say when accessing the Ob object, a capacity on an Oa object belonging to the Aa application is passed as a parameter to the other application Ab. To implement the protection specified by the application Aa in its view in a second step E2, the filter Fa (Ob) adds the filter Fa (Oa) and passes it as a parameter of the methl method instead of the direct reference to the object Oa. Similarly, to implement the protection specified by the Ab application in its view, the Fb (Ob) filter adds the Fb (Oa) filter and passes it as a parameter of the methl method instead of the received parameter.

The filter objects Fa (Ob) and Fb (Ob), when called, are therefore responsible for installing filter objects Fa (Oa) and Fb (Oa) for the references passed in parameter; in other words, two capacities illustrated by the filters Fa (Oa) and Fb (Oa) protecting access to the object Oa are added respectively in the applications Aa and Ab.

An example of the generated filter class F__Iab__V is shown below for the view Iab_V given previously, recalled below:

vi ew Iab_V {void methl (I1_V1 pi);

I2_V2 meth2 (); NOT void meth3 ();

}

For the views I1_V1 and I2_V2, filter classes F_I1_V1 and F_I2_V2 are created respectively. It is assumed that the two cooperating applications Aa and Ab are in the same JAVA environment and the following lines are still written in JAVA code, in which the public keyword means that the following declared method is accessible to all classes, the keyword void means that the following declared method when executed returns no results, and the keyword new designates a class creation operator:

publi c class F_Iab_V implements lab {lab obj;

public F_Iab_V (lab o) {obj = o;

}

publi c voi d methl (I1_V1 pi) {obj. methl (new F II VI (pi)); ;

public I2_V2 meth2 () {return (new F_I2_V2 (obj .meth2 ()));

}

public void meth3 () {

// propagate an exception

}

The variable obj is a reference to the next entity in the path to the object, the second filter or the real object. It is used to retransmit the call if it is authorized.

The F_Iab_V method is the constructor method of the filter class. It initializes the variable obj. When the Aa application imports a capacity from the name server and wants to associate the Iab_V view with it, it calls the constructor method, passing the received JAVA reference as a parameter.

The methl method retransmits a call which is therefore authorized, but it must associate with the capacity passed in parameter pi the view I1_V1. The methl method creates by the operator new a filter F_I1_V1 from the received parameter, then retransmits the call by passing in parameter pi the reference to the created filter.

The meth2 method retransmits the call and receives a capacity in return. It must associate the I2_V2 view with it. The meth2 method therefore creates an instance of the class F_I2_V2 from the received parameter and returns by the return instruction the reference to the filter object created in return from the meth2 method. The meth3 method does not retransmit the call since it is not authorized, and therefore propagates an exception.

The implementation when the cooperating applications Aa and Ab are both in the smart card respects the principles described above. On the other hand, when one of the two applications is outside the map, the layout is significantly different.

It is recalled that the method calls between a docking station SA, such as a terminal, and a smart card CP as shown diagrammatically in FIG. 6 are implemented from messages, called application protocol data units APDU between the docking station SA and the smart card CP, these method calls being made only according to the direction of the docking station towards the card. Indeed, the docking station and the smart card, or alternatively two smart cards or two controllers in a smart card or a terminal, comprise microcontrollers constituting data processing means which are respectively master and slave and which dialogue according to an asynchronous data exchange protocol which obliges the docking station to periodically interrogate the card so that it triggers an action in response to the docking station.

As a variant, the docking station in the following is replaced by another smart card, that is to say the cooperating applications Aa and Ab are installed respectively in two smart cards, or more generally in two controllers.

The asynchronous data exchange protocol implies that, for a call relating to an Obi object from the application Aa in the docking station SA to the application Ab in the card CP to which the object Obi belongs, when there is retransmission of a call between two filter objects Fa (Obi) and Fb ( Obl), relating to the Obi object, this retransmission of the call takes the form of a message exchange between the docking station and the card. A docking station of unknown origin (pirate) is then able to establish a message corresponding to a method call although it is not actually authorized to make this method call. This amounts to creating a capacity which is not possible in the protection scheme according to the invention. To protect the capabilities from these attacks, secrets, such as password mdp, possibly based on encryption methods, are used.

As shown in FIG. 6, when in a first step E3 the application Aa in the docking station SA calls the method meth2 on an object Obi belonging to the other application Ab in the card CP, that is to say -display when accessing the Obi object, and when in a second step E4 the result of this method call returns an access capacity on an Ob2 object belonging to the application Ab, the filter Fb (Obl ) creates the Fb filter (Ob2) in the operating system of the CP card for this access capacity. According to the invention, the filter Fb (Obl) then generates a secret, such as a password mdp which is stored in the filter Fb (Ob2) and returned to the filter Fa (Obi) which also stores it. Thus, when the filter Fa (Obi) creates the filter Fa (Ob2) in the docking station SA for the access capacity returned, the filter Fa (Obi) passes to the filter Fa (Ob2) the word of password mdp stored there. In other words, access to the object Ob2 is protected in the applications Aa and Ab respectively by two added capacities illustrated by the filters Fa (0b2) and Fb (0b2).

When in step E4 this capacity returned as a parameter is used to call a method on the Ob2 object, the call between the filters Fa (0b2) and Fb (Ob2) includes the password in the APDU message, this which allows the Fb filter (0b2) to verify that the ability to access the Ob2 object is valid.

The invention thus creates by naming a correspondence between an object and a capacity illustrated by a filter, managed by the operating systems in the data processing means, such as docking station and smart card. If an object is deleted in an application, the respective operating system destroys the corresponding filter.

Thus, the cooperation between an Ab application in the card with any application requires managing capacities that can take two formats, with password if the application is exported out of the card and without password if it remains in the menu.

The above protection scheme uses references, kinds of pointers, to JAVA objects that are almost capabilities. Indeed, since the JAVA language is safe, it is not possible in a JAVA program to establish a reference to an object and to call a method on this object. This implies that if an object 01 creates an object 02, the object 02 is not accessible from the other objects of the JAVA environment, as long as the object 01 does not transmit not explicitly to object 02 a reference to these other objects. This reference transmission can only be done by passing a parameter when an object calls object 01 or when object 01 calls another object.

Claims

1 - Method for controlling access between two applications (Aa, Ab) each cooperating by means of capacities on objects belonging to the other application, the applications cooperating through at least one operating system and being installed in a means data processing (CP), characterized by the following step: when one (Aa) of applications, called access requester application, is given access to an object (Ob; Obi) belonging to the other application (Ab), called access provider application, - create (E0) two capacities (Fa (Ob), Fb (Ob); Fa (Obi), Fb (Obl)) respectively in said requesting and supplier applications access, as objects; the capacity created in the access provider application (Ab) to limit access to said object (Ob) and; the capacity created in the access requesting application (Aa) to associate the access requesting application with the capacity created in the access provider application (Ab).

2 - Method according to claim 1, comprising when accessing (El; E3) an object (Ob; Obi) belonging to one (Ab) of the applications, if a second object (Oa; Ob2) belonging to one (Aa; Ab) of the applications is passed to this application, the step of adding (E2, E4) two other capacities (Fa (Oa), Fb (Oa); Fa (Ob2), Fb (Ob2) ) respectively in the applications (Aa, Ab) to protect access to the second object.

3 - Method according to claim 2, according to which the ability to access the second object (Oa; Ob2) belonging to one of the applications is passed as a parameter or as a result to the other application.

4 - Method according to any one of claims 1 to 3, characterized by the export of a capacity from an application (Ab) to the other application (Aa) by associating it with a symbolic name, and the import of the exported access capacity in the other application by interrogating a name server with the symbolic name.

5 - Method according to any one of claims 1 to 4, according to which the applications (Aa, Ab) are located in a common data processing means (CP).

6 - Method according to any one of claims 1 to 4, according to which the applications (Aa, Ab) are respectively located in two remote data processing means (SA, CP) exchanging access messages to remote objects .

7 - Process according to claim 6 when it depends on claim 2 or 3, according to which the step of adding two other capacities (E4) comprises storing a secret word (mdp) in the two other capacities ( Fa (Ob2), Fb (Ob2)) passed to them by the two capacities (Fa (Obi), Fb (Obl)) previously created.

8 - Process according to claim 6 or 7, according to which the data processing means are respectively included in a smart card (CP) and a docking station (SA) of the smart card. 9 - Process according to claim 6 or 7, according to which the data processing means are included respectively in two smart cards.

10 - Process for generating applications characterized in that it comprises:

- a step of developing an application (Ab) comprising an object (Ob) or several objects (Ob, Obi), without restriction of access;

a step of defining rules for access rights to the object (Ob) or to the objects (Ob, Obi) included within the application from a second application (Aa) or from several other applications;

a step of transforming the application (Ab) comprising the object or objects (Ob, Obi) by adding to said application (Ab), filtering means (Fa, Fb) of the accesses to said object (Ob) or to said objects ( Ob, Obi) for implementing the access control method according to claims 1 to 4;

- a step of implementing the transformed application within a data processing means (CP, SA).

11 - Method according to claim 10 according to which the data processing means is included in a smart card.

12 - Method according to claim 10 according to which the data processing means is included in a docking station (SA) of the smart card.