DE102007041873A1 - Patch installing method for e.g. object oriented programming language card in mobile phone, involves forming class hierarchy using classes in program package, and including patch in class hierarchy as subclass of one of classes - Google Patents

Abstract

The method involves forming class hierarchy using classes in a program package (38) in a smart card module (10) e.g. Java(RTM: Object oriented programming language) card, provided with an object-oriented runtime environment (30). A patch (P) is included in the class hierarchy as a subclass of one of the classes, which is recorded in an export component. A new class field structure is formed for the patch. A class pointer of an instance field structure pointing to the class is changed in another class pointer pointing to the patch. An independent claim is also included for a machine-readable data medium having a set of instructions executed by a processor of a smart card module for performing a method for installing a patch in the smart card module.

Description

The This invention relates generally to the technical field of installation patches in smart card modules. A smartcard module in the wording of the present document, for example, the design of a Have a smart card or a compact chip module.

Smart card modules are used for a variety of applications. Next the originally prevailing embodiments as smart cards or plug-in chip modules - z. B. SIMs for Mobile phones - are becoming increasingly smart card modules designed for fixed installation in equipment are. Such built-in modules can, for example, as NFC modules (NFC = Near Field Communications) be designed which short the function of a smartcard with a wireless communication interface Combine range.

The presently considered embodiments of smart card modules have system programs that provide an object-oriented runtime environment. Such smart card modules are z. B. known under the brand Java Card. The document "Runtime Environment Specification Java CardTM Platform, Version 2.2.2", March 2006 , published by Sun Microsystems, Inc. of Santa Clara, USA, describes the runtime environment of Java Card modules. This document is hereby incorporated by reference.

Lots Smartcard modules contain extensive and complex software. This This is especially true for Java Card modules because these are relative are complex and therefore primarily for demanding Tasks are used. Even if the in a smart card module included software is created with great care, Errors can not be completely ruled out. To such Correct errors before delivery of the smart card module, It is known in the course of completion or initialization of the smart card module to introduce patches into the module. According to the common usage is here under a Patch or "patch" program code understood that is not a stand-alone System or application program, but for modification of an existing program - in particular for error correction or functional extension - serves.

The just mentioned patch possibility is after the completion or initialization of the smart card module not more usable. Will be a serious error after this time discovered, it may require replacement of the smart card module become. In a smart card module in chip card design is the problem less in the cost of a new smart card, but rather in the logistical effort that arises when the chip card is already at the end user. These it is a built-in smart device module such as As an NFC module, so many may already be produced devices unusable or strong in their function limited. Depending on the value of the devices can this causes great damage.

at Java Card modules, it is in principle conceivable, an existing - erroneous - package (package) delete and a corrected version of the program package reload. However, this is only possible if not yet Objects have been created and no other program package yet the program package to be corrected has been linked. These requirements are very restrictive and prevent in most cases patching a smart card module that is currently being personalized or already at the end user.

The U.S. Patent 6,202,208 discloses a technique for patching a program executed by a Java ^™ Virtual Machine - not a Java Card Virtual Machine. When importing a patch, at least one entry in a method table of the program is changed so that the changed entry refers to a method body provided by the patch. In this way, the program can be changed during operation. This functionality is z. B. for telecommunications switching systems important in which as no downtime should occur.

The The invention has the object of a technique for installing a patch in a smart card module that can be used extensively is, in particular even if the smart card module already in the last stages of production or even at End user. It is also an object of some embodiments the invention, as far as possible existing data in the smart card module largely to get over the patch process away.

According to the invention, this object is achieved by a method having the features of claim 1, a method having the features of claim 6, a machine-readable data carrier according to claim 15 and a smart card module according to claim 16. The dependent claims relate to optional features of some embodiments of the invention.

One The first aspect of the invention is based on the basic idea, the patch into the class hierarchy as a subclass of the patched class. This allows the existing object-oriented runtime environments Polymorphism mechanism used in a natural way to correctly place the code in the patch into the Include call order of the classes of the program package. In some embodiments the patch will be similar to dynamic reloading Class created in the memory of the smart card module.

In In some embodiments, the patch is further incorporated into the Class hierarchy as superclass of each original Subclass of the patched class inserted. This measure Make sure that elements (such as methods or fields) of the patch of derived classes in the same program package correctly addressed become. To the patch also for external derived classes (ie subclasses of the patched class that are in another Program package) will in some embodiments also for at least one overwritten by the patch Element (for example, a method or a field) of the patched class the patch is entered in an export component.

According to one second aspect of the invention is at least one instance field structure the patched class and / or a subclass thereof to the patch customized. This has the considerable advantage that already in the smart card module contained data (eg personal data of the user, the two personalization have been entered in the smart card module) can be largely or completely preserved. Customizing the instance field structure may be in some embodiments z. For example, include a field appended or inserted and / or that the type of a field is changed.

In many designs are taken to a unauthorized patching of the smart card data carrier, which could cause significant damage, too prevent. For example, it may be provided that the patch to be patched Class or superclass determines or at least influences whether the patch may be installed. This allows the Authentication requirements are set class-specific, and the inheritance mechanism that exists in object-oriented runtime environments be used advantageously to the admissibility of the patching process.

In the embodiments of the present document mainly smart card modules according to the java card standard described. However, the invention is also suitable for use with other smart card modules, which have similar structures. This can For example, smart card modules according to the .NET standard.

Of the inventive machine-readable data carrier can be used as a physical medium - eg. B. as a floppy disk or CD-ROM or semiconductor memory - or as non-physical Medium - eg. As transmitted over a computer network Signal - be configured. The disk can for example, in the manufacture and / or completion and / or Initialization of the smart card module used to be a patch routine with the functionality according to the invention into the smart card module.

Further Features, advantages and objects of the invention will become apparent from the following detailed description of an embodiment and several Implementation alternatives. It is on the schematic Drawings referenced in which:

1 a block diagram with functional units of a smart card module according to an embodiment of the invention,

2 a representation of portions of the memory contents of the smart card module prior to installing a patch,

3 a representation like in 2 after installing the patch,

4 a flow diagram of a method for installing the patch,

5 a flowchart of the method of 4 upstream procedure for authorization verification, and

6 an exemplary representation of the adaptation of an instance field structure by inserting an additional field.

This in 1 illustrated smart card module 10 is in the present embodiment as a chip module for soldering in a host device -. B. a mobile phone - designed. The smart card module 10 has a processor 12 , a store 14 , a host interface 16 and a radio interface 18 on. This will be the host interface 16 used for wired communication with the host device while the radio interface 18 for short-range wireless communication (NFC = Near Field Communications) to an external terminal. In alternative executions is the smart card module 10 however, designed as a conventional chip card or as a conventional chip module with only one interface for wired or wireless communication with an external terminal.

The memory 14 is divided into several memory fields. In the present embodiment, memory arrays are a ROM formed as a read-only memory 20 , a non-volatile overwritable memory designed as an EEPROM 22 and a random access memory configured as RAM 24 intended.

The smart card module 10 is designed according to the Java Card standard. It has system programs 26 on, which is partly in read-only memory 20 and partly in non-volatile overwritable memory 22 and data in memory 24 access. The system programs 26 include a hardware-related operating system 28 and an object-oriented runtime environment 30 , The runtime environment 30 assigns a virtual machine 32 on, which is configured in the present embodiment as a JCVM (Java Card Virtual Machine). It is also part of the runtime environment 30 a class library 34 providing application programming interfaces and utilities. In particular, the runtime environment points 30 - In the present embodiment, the class library 34 - a patch routine 36 which controls the patch functions described in more detail below.

In 1 is one in the smart card module 10 installed program package 38 For example, this is one of the smart card module 10 executed application (applet) forms. It is understood that additional, in 1 not shown program packages may be present. The program package 38 has a plurality of classes, of which in 1 three classes A, B, C are shown by way of example. The classes A, B, C form a class hierarchy. In this class hierarchy, class A is the immediate superclass of class B, and class C is an immediate subclass of class B. This is by reference 40 . 42 which designates for each class its superclass.

In non-volatile overwritable memory 22 are class field structures 44 and instance field structures 46 created in 1 are shown only schematically. Each class field structure 44 contains the fields of the class variables for each class. Each instance field structure 56 is always assigned to a class instance - that is, one object each - and contains the fields of the instance variables of this object.

In the embodiment described here, both the class field structures are located 44 as well as the instance field structures 46 in a heap 48 which is in an area of non-volatile overwritable memory 22 is created. However, embodiments are also provided in which the class field structures 44 as static data structures outside the heap 48 be created.

1 also shows a patch package 50 that's over the host interface 16 into the smart card module 10 is read. The patch package 50 contains one or more patches P. Each patch P can optionally have one adaptation description 52 which specifies, in what way instance field structures affected by the patch P. 46 need to be changed when installing patch P. For example, the patch package 50 similar to a CAP file (CAP = Converted Applet) be constructed, with any existing adaptation descriptions 52 contained in an additional component. The various data components contained in such a CAP file are so well known and therefore in 1 Not shown.

The patch package 50 is in the present embodiment by the usual in Java Card modules mechanisms such as a program package (Package) in the smart card module 10 loaded. When installing the patch package 50 however, the "pseudo-application" becomes the patch routine 36 execute the patch P into the program execution environment of the smart card module in the manner described below 10 integrates. Loading a patch package as a "pseudo-application" is already in the German patent application 10 2007 003 580.4 Giesecke & Devrient GmbH, filed January 24, 2007.

2 and 3 each show data structures in the non-volatile overwritable memory 22 of the smart card module 10 before or after installing the patch P through the patch routine 36 , The steps taken by the patch routine 36 to install the class P patch P as the class to be patched are in 4 shown. In other words 3 the result, if the procedure according to 4 on memory structures according to 2 is applied.

The in 2 shown original memory contents corresponds to the representation of 1 with the three classes A, B, C, their class hierarchy by the references 40 . 42 indicated on the respective superclass. Every reference 40 . 42 is contained in a class component CLASS of the corresponding method B, C. In a manner known per se, the classes CLASS contain additional information, for example a table with references to bytecode for the implemented methods and a table of the interfaces defined in the class. Such an interface 54 named "patchable" is shown in the class component of class B.

Classes A, B, C also have bytecodes of the methods they implement. 2 shows an example of an implementation of the method "authorize", whose meaning will be described later.

The program package 38 ( 1 ) with classes A, B, C also has an export component 58 ( 2 ), the references to all exported elements (classes, methods and fields) of the program package 38 contains. 2 shows an example of such a reference 60 which relates to an item exported from class B and is therefore directed to class B. The representation in 2 is here to be understood only symbolically. In a real implementation, the information of the reference would be 60 in a Constant Pool component of the program package 38 are located. However, for the sake of clarity, these and other details are not described and shown in detail here because they are well known in the context of Java Card environments.

Before the patching process, the heap points 48 the in 2 shown memory contents on. A class field structure 44B contains fields for the class variables of class B, and a class field structure 44C Contains a field for a class variable of derived class C. Bidirectional References 62B . 62C - in summary as references 62 - allow, from class B, C, to the associated class field structure 44B . 44C to access and vice versa.

In the presentation of 2 It is assumed that two instances of class B and one instance of class C exist. Corresponding instance field structures 46B.1 . 46B.2 and 46C.1 for the fields of these instances are in 2 shown. Because class C is derived from class B, the instance field structure assigns 46C.1 the same first field as the instance field structures 46B.1 . 46B.2 on that in 2 is characterized by an oblique hatching. It also contains the instance field structure 46C.1 another, in 2 vertical hatched field for an additional instance variable of class C. References 64B.1 . 64B.2 and 64C.1 - in summary as references 64 denotes - allow, from the instance field structures 46B.1 . 46B.2 and 46C.1 to access the assigned classes B and C.

This in 4 The method shown for installing the patch P, which concerns the class B as a class to be patched, begins in step S1 with the creation of suitable memory structures. In particular, these are the memory structures for the various components of the patch P and, if the patch P contains at least one class variable, a corresponding class field structure 44P (shown in 3 ).

The patch P is essentially constructed like a class and therefore has the same components as a class. Among other things, these are a class component CLASS, bytecode for the methods implemented by the patch P, a constant pool, and so on. The application of the memory structures in step S1 ( 4 ) corresponds approximately to the dynamic reloading of a class, so that the known functions of the runtime environment 30 can be used without or with minor changes. However, unlike a full class, the patch does not implement all the methods of the class to be patched, but only those methods that are broken in the class being patched or that should be modified for other reasons.

In step S2, the patch P is now inserted into the class hierarchy as a subclass of the class to be patched - here B -. This will be a reference 66 is entered on the class B in the class component CLASS of the patch P and thus defines the class B as the superclass of the patch P. This step can also be combined with step S1.

Derived classes of the patched class should call a method of the patched class only if this method has not been replaced by the patch P. For classes internally derived from the patched class - that is, classes whose superclass is the patched class and which are in the same program package 38 like the patched class - this is achieved by entering patch P as the superclass of these derived classes. This happens in steps S3 and S4. For example, the derived classes may be identified in step S3 by checking their superclass references (bytecodes "instance_of" and "checkcast", respectively).

In this example, class C is the only internally derived class, and their reference 42 is directed to the patch P in step S4 to define P as the superclass of C.

Overall, the patch P has been integrated into the class hierarchy "between" the patched class B and its original subclasses - here C - through the steps S2, S3 and S4. This makes it possible to use the polymorphism provided by the Java Card environment to incorporate the methods contained in the patch P in the desired manner in the program package 38 integrate. Thus, a method call from class C, which involves a method contained in class B and now overwritten by patch P, is executed correctly by patch P. However, a class B method not overwritten by patch P is still performed by the class B implementation.

Classes are not in the program package 38 ("external classes") and those derived from the patched class B are from the Java Card runtime environment 30 dynamically via the export component 58 of the program package 38 linked. Also in this case, a correct integration of the patch P should be ensured. For this purpose, in step S5, all export tokens of the export component 58 , which refer to an element originally provided by the patched class B and replaced by the patch P, are changed so that they now refer to the patch P. As previously mentioned, in many implementations of the method described herein, modification of the export tokens requires changing the entries in the constant pool component of the patched class B.

The adaptation made in step S5 is in 3 This demonstrates that the reference 60 the export component 58 was changed so that it no longer points to the patched class B, but to the patch P. As a result of this measure, the patch P also correctly enters the calling order of the Java Card runtime environment with regard to external derived classes 30 involved.

If patch P does not declare objects with their own instance variables, then the installation process is now complete, as in 4 is indicated by a dashed arrow. However, in some embodiments, the class references may also be required in this case 64 some or all instance field structures 46 , which so far on the to be patched class - z. For example, class B - to change to references to the patch P. In these embodiments, steps similar to steps S6 and S7 are always executed.

If the methods of the patch P require additional fields for instance variables and / or require a different type for existing fields, then in any case, the steps S6-S10 are executed in which the already in the heap 48 existing instance field structures 46 be adapted to the patch P. This ensures that existing objects (eg with personalized data) are preserved throughout the patching process.

In step S6, all instance field structures become 46 searched for, which are assigned to the class to be patched. This can be done by heap 48 is searched and the references 64 the instance field structures 46 to be analyzed. The references 64 the found instance field structures 46 are changed in step S7 so that they refer to the patch P. Furthermore, in step S8, the additional required fields are added to the instance field structures 46 changed or the type of existing fields changed (eg change of a field of the type "short" into a field of the type "int"). In this case, the previous field content is preserved as far as possible and - in case of a type change - adapted to the new type.

In the in 3 In the example shown, steps S6-S8 relate to the two instance field structures 46B.1 and 46B.2 whose references 64B.1 . 64B.2 be directed to the patch P in step S7. Further, in the example of 3 the instance field structures 46B.1 and 46B.2 by an additional field - which is characterized by a horizontal hatching - extended.

While in the example according to 3 the horizontally hatched field only to the instance field structures 46B.1 and 46B.2 In some embodiments of the invention, a mechanism has been provided which substantially reconfigures the instance field structures identified in step S6 46 allowed. The patch routine evaluates this 36 in these embodiments in the patch package 50 included adjustment description 52 out. This adjustment description 52 indicates how to customize the existing instance field structures 46 should be done.

In one embodiment, the adjustment description includes 52 an entry "objektfeld_anpassungsbeschreibung_1", which can be defined as follows, for example:

Such an exemplary entry indicates that an old instance field structure 46 - z. For example, class B has five fields while the custom instance field structure 46 ' - z. For example, class P should have six fields and the new field should be inserted between the earlier fields with index values 2 and 3. 6 illustrates the customization of an instance field structure 46 with field contents F0-F4 according to this entry.

In the further steps S9 and S10, those instance field structures become 46 searched for and adapted, the subclasses are assigned to the class to be patched. Steps S9 and S10 are executed similarly to steps S5 and S8; a change of class references 64 is not required here. To adapt the instance field structures 46 in step S10, the same rules and / or customization descriptions may be used 52 as in step S8, since each instance field structure processed in step S10 46 the same initial sequence of fields as each instance field structure edited in step S8 46 contains the superclass to be patched. The instance field structures processed in step S10 46 however, because they are associated with derived classes, they may have additional ("attached") fields. These fields must be preserved in the adaptation in step S10.

In the in 3 In the example shown, steps S9 and S10 relate to the instance field structure 46C.1 assigned to the derived class C. In this instance field structure 46C.1 becomes the additional field required by patch P (in 3 horizontally hatched), before the (in 3 vertically hatched) field for the additional instance variable of class C.

In embodiments of the steps just described, the existing instance field structures 46 not changed (or at least no fields are inserted between existing fields), so that also on the adjustment description 52 can be waived. Fields which may additionally be required by the patch P are created in these embodiment variants in a separate patch field, for example at the end of each instance field structure 46 or separated from it in the heap 48 can be located. The runtime environment 30 then has the task to direct accesses to such fields suitable to the respective storage locations.

It is understood that the division of steps S6-S8 and S9-S10 in FIG 4 was chosen only for reasons of clarity. In particular, in one implementation, steps S6 and S9 may be combined so that the entire heap 48 by instance field structures 46 is searched and for each found structure according to the purpose of their reference 64 either steps S7 and S8 or step 10 or no further processing is performed (the latter when the instance field structure 46 is not associated with either the patched class or any derived class).

Furthermore, it is understood that in possible implementations the in 4 shown steps in different, possibly from 4 differ in the order and / or interlocked (interleaved) can be performed. However, the installation of the patch P always takes place in the embodiments described here as an atomic transaction.

The method described here allows installation of the patch P in an unsecured environment, such as when the smart card module 10 already at the end user. Since a faulty or maliciously-programmed patch P can cause high damage, it is important in the embodiments described herein to safely prevent any unauthorized installation. For this purpose, known signature and authentication checks can be used, the z. When loading the patch package 50 or before starting the patch installation.

In In this context, it is a particular feature of many embodiments the invention that the class to be patched or a superclass of it - here z. B. classes B or A - determined or at least influenced if the patch installation allowed becomes. In this way, different security requirements be considered without problems. For example, can a class that maintains only an address book, the installation allow a patch while a security critical Class, the z. For password verification is responsible, no change allowed.

In the embodiment described here performs the patch routine 36 before the actual, in 4 The patch process shown in FIG. 1 performs an authorization check as exemplified in FIG 5 is shown. The process starts in step T1 with the patch routine 36 the patch package 50 checked and the class to be patched and the associated program package - here z. Class B and the program package 38 - identified.

In step T2, the patch routine checks 36 now, whether the patching of the identified class is basically allowed. For this purpose, in the present exemplary embodiment it is determined whether the interface "patchable" is implemented here in the class to be patched - in this case B - or a superclass thereof - here A. This interface, which is used as a so-called "tagging interface", can be defined, for example, as follows:

In the present example is according to 2 the interface "patchable" in class B as interface 54 defined, and the method "authorize" is by the bytecode 56 implemented. The method is therefore continued with step T3. Otherwise, the procedure would be aborted with an error message and the patch P would not be installed.

In Step T3 is determined by a call to the "authorize" method, whether the patch P may be installed. This is basically the class that implements the patchable interface itself responsible for safety. So the method awaits "authorize" in this example the parameters "buffer", "offset" and "length", which depends on authorization data of the patch P - z. For example, a password or a signature - refer. Further may be provided in some embodiments that the patch P is encrypted in whole or in part; in this case In addition, the code must be decrypted.

The Functions for the authorization of the patch P and, if necessary, for Decryption of program code does not necessarily need to be implemented in the class of the method "authorize". Much more In some embodiments, it is provided that the method "authorize" accesses functions from a Security domain be provided.

In keeping with common usage, a security domain is one on the smart card module 10 located application that performs key management tasks and provides other safety-critical services. However, in embodiments which use a security domain, an explicit identification of the pachable classes by the inter-patch "patchable" is still provided for security reasons.

When Defense against attacks in which the calculation process the authorization check in step T3 external interference is disturbed, the authorization verification or part of it can be done several times by z. For example, the method "authorize" is called multiple times. The results are then compared, and permission to install the patch will only be issued if the match is positive.

If it is determined in step T4 that the authorization for installing the patch P has been issued, in step T5, the installation procedure according to 4 for the class B found in step T1 as too running patching class. Otherwise, the procedure is aborted.

It It is understood that at least the one executed by the class to be patched Step T3 must be completed before the actual patching process begins in step T5. In other words, during In the patching process, no thread that is the class to be patched will be active or objects thereof.

In the embodiment described here it is sufficient if the interface is "patchable" in the class to be patched or one of its superclasses is implemented. The property, patchable Being thus is hereditary. The usual in Java Card environments Inheritance mechanism can also be used advantageously if a derived class for security reasons should not be patchable. This derived class then needs just to reimplement the interface "patchable".

It understands that in modifications instead of an interface "patchable" also an interface "non-patchable" can be provided, which the Patchability of a class and its derived classes.

In further alternative embodiments, the classes of a program package 38 other than by implementing an interface, whether a patch should be allowed and, if so, what security checks should be made. The actual authorization is then through the patch routine 36 carried out. Embodiments are also provided in which the authorization check is performed entirely by the patch routine 36 - is performed without being influenced by the class to be patched.

It it should be understood that the embodiments described herein and variants to see only as examples are. Further modifications and combinations of the ones described here Features will be readily apparent to those skilled in the art.

QUOTES INCLUDE IN THE DESCRIPTION

This list The documents listed by the applicant have been automated generated and is solely for better information recorded by the reader. The list is not part of the German Patent or utility model application. The DPMA takes over no liability for any errors or omissions.

Cited patent literature

• - US 6202208 [0007]
• - DE 102007003580 [0030]

Cited non-patent literature

• - "Runtime Environment Specification Java CardTM Platform, Version 2.2.2", March 2006 [0003]

Claims (16)

Method for installing a patch (P) in a smart card module ( 10 ), whereby the smart card module ( 10 ) an object-oriented runtime environment ( 30 ) and at least one program package ( 38 ) having a plurality of classes (A, B, C) constituting a class hierarchy, characterized in that the patch (P) is inserted into the class hierarchy as a subclass of the patched class (B). Method according to claim 1, characterized in that the class hierarchy of the program package ( 38 ) has at least one subclass (C) of the class (B) to be patched before the patching, and that the patch (P) is inserted into the class hierarchy as the superclass of each such subclass (C). Method according to Claim 1 or Claim 2, characterized in that for at least one element of the patched class (B) affected by the patch (P), the patch (P) is converted into an export component ( 58 ) of the program package ( 38 ) is entered. Method according to one of claims 1 to 3, characterized in that for the patch (P) a new class field structure ( 44P ) is created. Method according to one of claims 1 to 4, characterized in that at least one before the patching on the class to be patched class (B) referring class reference ( 64B.1 . 64B.2 ) at least one instance field structure ( 46B.1 . 46B.2 ) into a class reference referring to the patch (P) ( 64B.1 . 64B.2 ) will be changed. Method for installing a patch (P) in a smart card module ( 10 ), whereby the smart card module ( 10 ) an object-oriented runtime environment ( 30 ) and at least one program package ( 38 ) having a plurality of classes (A, B, C), characterized in that at least one instance field structure ( 46B.1 . 46B.2 ) of the patched class (B) and / or at least one instance field structure ( 46C.1 ) of a subclass (C) of the patched class (B) is adapted to a change caused by the patch (P). Method according to claim 6, characterized in that the adaptation of the at least one instance field structure ( 46B.1 . 46B.2 . 46C.1 ) includes appending or inserting a field or changing a type of a field. Method according to claim 6 or claim 7, characterized in that when adapting the at least one instance field structure ( 46B.1 . 46B.2 . 46C.1 ) the previous content of the instance field structure ( 46B.1 . 46B.2 . 46C.1 ) preserved. Method according to one of claims 6 to 8, characterized in that the patch (P) an adjustment description ( 52 ), which specifies how the instance field structure ( 46B.1 . 46B.2 . 46C.1 ) should be adjusted. Method according to one of claims 6 to 9, characterized in that the method further according to a of claims 1 to 5 is configured. Method according to one of claims 1 to 10, characterized in that the class to be patched (B) or a superclass (A) of the class (B) to be attached or at least influences whether the patch (P) may be installed. Method according to claim 11, characterized in that that the class to be patched (B) or the superclass (A) is an interface with an authorization verification method implemented. Method according to one of claims 1 to 12, characterized in that the smart card module ( 10 ) is designed as a Java Card. Method according to one of claims 1 to 13, characterized in that the patch in a patch package ( 50 ) in CAP format into the smart card module ( 10 ) is loaded. Machine-readable data carrier with program instructions, which are adapted to a processor ( 12 ) of a smart card module ( 10 ) for carrying out a method according to one of claims 1 to 14. Smart card module ( 10 ) with a processor ( 12 ) and at least one memory ( 14 ) arranged to carry out a method according to any one of claims 1 to 14.