Classifications

• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F21/60—Protecting data
  • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
  • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F2221/2141—Access rights, e.g. capability lists, access control lists, access tables, access matrices
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F2221/2153—Using hardware token as a secondary aspect

Definitions

• 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.
• 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.
• 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.
• an access list indicating the access rights Dlj to Dij on the object respectively for the users UI to UI.
• 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.
• 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.
• 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.
• document US 5781633 illustrates an earlier technique allowing filtering, by means of capacities, of exchanges of object references between different processes.
• the process disclosed by the document is ineffective.
• the access requester process can modify the filter sent to it as it pleases and access
• the invention relates more particularly to an access control mechanism based on a scheme of
• the invention implements a capacity model in the context of the smart card to pursue two objectives:
• 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.
• 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.
• 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.
• 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.
• the data processing means is included in a smart card.
• the data processing means is included in a docking station for the smart card.
• 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.
• the method 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.
• 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.
• the applications can be implemented in a common data processing means, for example in a smart card or a terminal.
• a smart card the Verifications of the code loaded in the smart card ensure that a capacity cannot be created by a pirate programmer.
• 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 .
• FIG. 1 shows a matrix of access rights already commented on ;
• FIG. 2 is a block diagram showing interfaces between a bank application and a client application
• FIG. 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.
• FIG. 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.
• 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.
• a BA bank that is to say a bank application in a server, manages accounts for clients.
• 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.
• PIN Personal Identity Number
• 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.
• this programming tool specifies in the interfaces used the capacity that must be transferred during a parameter transmission between applications.
• view view in English
• the word "String” designating a character string object:
• 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.
• 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.
• 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.
• 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.
• a docking station such as a bank terminal, a point of sale or a mobile radiotelephone terminal, in which the card is inserted.
• 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.
• 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:
• Iab_V ⁇ void methl (I1_V1 pi); I2_V2 meth2 (); NOT void meth3 ();
• 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.
• 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.
• 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.
• 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
• 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.
• 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.
• the protection policy for each application according to the invention 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 .
• 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.
• 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.
• 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.
• 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.
• 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.
• a capacity on an Oa object belonging to the Aa application is passed as a parameter to the other application Ab.
• 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.
• 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.
• I2_V2 meth2 (); NOT void meth3 ();
• 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:
• 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.
• 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 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.
• 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.
• 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.
• secrets such as password mdp, possibly based on encryption methods, are used.
• the filter Fb (Obl ) creates the Fb filter (Ob2) in the operating system of the CP card for this access capacity.
• 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.
• 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.
• 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).
• step E4 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.
• 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.

Landscapes

• Engineering & Computer Science (AREA)
• Theoretical Computer Science (AREA)
• Computer Security & Cryptography (AREA)
• Bioethics (AREA)
• General Health & Medical Sciences (AREA)
• Computer Hardware Design (AREA)
• Health & Medical Sciences (AREA)
• Software Systems (AREA)
• Physics & Mathematics (AREA)
• General Engineering & Computer Science (AREA)
• General Physics & Mathematics (AREA)
• Databases & Information Systems (AREA)
• Storage Device Security (AREA)

Applications Claiming Priority (3)

Publications (1)

Family

ID=9553271

Family Applications (1)

Country Status (5)

Families Citing this family (38)

Family Cites Families (11)

• 1999
  • 1999-12-10 FR FR9915791A patent/FR2802319B1/fr not_active Expired - Fee Related
• 2000
  • 2000-12-08 US US10/148,954 patent/US7490333B2/en not_active Expired - Fee Related
  • 2000-12-08 WO PCT/FR2000/003463 patent/WO2001042887A2/fr not_active Ceased
  • 2000-12-08 AU AU26857/01A patent/AU2685701A/en not_active Abandoned
  • 2000-12-08 EP EP00990048A patent/EP1240570A2/de not_active Withdrawn

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events