EP2111578A1 - Installieren eines patch in einem smartcard-modul - Google Patents

Installieren eines patch in einem smartcard-modul

Info

Publication number
EP2111578A1
EP2111578A1 EP08707129A EP08707129A EP2111578A1 EP 2111578 A1 EP2111578 A1 EP 2111578A1 EP 08707129 A EP08707129 A EP 08707129A EP 08707129 A EP08707129 A EP 08707129A EP 2111578 A1 EP2111578 A1 EP 2111578A1
Authority
EP
European Patent Office
Prior art keywords
patch
smart card
card module
application
routine
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
EP08707129A
Other languages
English (en)
French (fr)
Inventor
Robert Pinzinger
Jörn TREGER
Ludger Holtmann
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Giesecke and Devrient GmbH
Original Assignee
Giesecke and Devrient GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Giesecke and Devrient GmbH filed Critical Giesecke and Devrient GmbH
Publication of EP2111578A1 publication Critical patent/EP2111578A1/de
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/355—Personalisation of cards for use
    • G06Q20/3552—Downloading or loading of personalisation data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/34—User authentication involving the use of external additional devices, e.g. dongles or smart cards
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/572—Secure firmware programming, e.g. of basic input output system [BIOS]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G06F8/66—Updates of program code stored in read-only memory [ROM]
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • G07F7/1008—Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system

Definitions

  • a smart card module in the wording of the present document may be in the form of a smart card or a compact chip module.
  • Smartcard modules are used for a variety of applications.
  • chip cards or plug-in chip modules - e.g. SIMs for mobile phones - Smartcard modules are increasingly being developed for permanent installation in devices.
  • NFC Near Field Communications
  • smart card module designs include system programs that provide a runtime environment for running applications and a loader for loading applications into the smart card module.
  • Such smartcard modules are e.g. known under the Java Card brand.
  • the just-mentioned patch option is no longer usable after the completion or initialization of the smart card module. If a fatal error is detected after this time, it may be necessary to replace the smart card module.
  • a smart card module in smart card design the problem is less in the cost of a new smart card, but rather in the logistical effort that arises when the smart card is already at the end user.
  • it is a smart card module permanently installed in a device, such as a smartcard module. an NFC module, many of the devices already produced may be unusable or severely restricted in their function. Depending on the value of the device can cause great damage.
  • Modified method table of the program so that the changed entry refers to a method body provided by the patch.
  • the program can be changed during operation.
  • This functionality is e.g. important for telecommunications switching systems, where as no downtime should occur.
  • the invention has the object to provide a technique for installing a patch in a smart card module even after the completion or initialization of the smart card module, which requires little effort and only minor changes to existing components and structures.
  • this object is achieved by a method having the features of claim 1, a method having the features of claim 11 and a smart card module having the features of claim 12.
  • the dependent claims relate to optional features of some embodiments of the invention.
  • the invention is based on the basic idea of using the known function of the smart card module for loading applications and also for introducing the patch into the smart card module. For this purpose, it is provided according to the invention to load a pseudo-application containing the patch into the smart card module by means of the load program and to call an installation routine contained in the pseudo-application which in turn includes the patch of a patch routine contained in the system programs. splits to install the patch to a location outside of the pseudo-application.
  • the "packaging" of the patch into the pseudo-application according to the invention has the considerable advantage that functions and structures known per se, such as are known per se, are used. Smart card modules according to the Java Card standard are used to achieve the patch functionality. For example, in some embodiments, only the patch routine is to be newly developed, and this patch routine can also be based on already existing functions for introducing patches during the initialization and / or completion of the smart card module. The loader actually intended for loading regular applications can in some embodiments also be used without any change for loading the pseudo application containing the patch.
  • the method according to the invention is transparent to the outside world.
  • the patched pseudo-application patch may therefore be used in any manner, e.g. be introduced into the smart card module in an OTA (OTA) charging process.
  • OTA OTA
  • the patch is for at least one of the system programs of the smart card module.
  • the patch may be written into a separate patch area in a non-volatile overwritable memory of the smart card module.
  • the patch is secured by a signature.
  • an identifier can be provided which ensures that only an uninterrupted sequence of consecutive patches can be installed.
  • any cryptographic checksums and authentications can be used, to safeguard the procedure against unauthorized modification of the programs stored in the smart card module.
  • smart card modules are described according to the / cu ⁇ C ⁇ rd standard.
  • the invention is also suitable for use with other smart card modules having similar structures. These can be, for example, smart card modules according to the .NET standard.
  • FIG. 1 is a block diagram with functional units of a smart card module according to an embodiment of the invention
  • FIG. 2 shows a representation of the system programs and the pseudo-application in the memory of the smart card module according to FIG. 1 during the installation of the patch
  • FIG. 3 is a flow chart of a method for installing a patch in the smart card module of FIG. 1.
  • the illustrated in Fig. 1 smart card module 10 is designed in the present embodiment as a chip module for soldering in a host device - eg a mobile phone - configured.
  • the smart card module 10 has a processor 12, a memory 14, a host interface 16 and a radio interface 18.
  • NFC Near Field Communications
  • the memory 14 is divided into several memory fields.
  • a non-volatile overwritable memory 22 designed as an EEPROM and a random access memory designed as a RAM 24 are provided as memory fields.
  • the smart card module 10 is designed according to the Java Card standard. It has extensive system programs 26, which are partly in read-only memory 20 and partly in non-volatile rewritable memory 22 and access data in working memory 24.
  • the system programs 26 form an operating system 28, a runtime environment 30, and a set of utility programs 32.
  • the operating system 28 provides hardware-related functions used by the runtime environment 30 and utilities 32.
  • the runtime environment 30 includes a virtual machine 34, which in the present embodiment is designed as a JCVM (Java Card Virtual Machine). Further, as part of the runtime environment 30, a class library 36 is provided which provides application programming interfaces.
  • the system programs 26 contain a load program 38 ⁇ installer) and a patch routine 40 whose operation will be described in detail later.
  • the patch routine 40 is part of the class library 36, while the load program 38 is configured as one of the auxiliary programs 32.
  • the loader 38 and / or the patch routine 40 may be included in other outline units of the system programs 26.
  • all system programs 26 are common components of a Java Card module.
  • the patch routine 40 may already be provided during the production of the smart card module 10.
  • the patch routine 40 is introduced into the non-volatile rewritable memory 22 at a later point in time-for example during the completion or initialization of the smart card module 10.
  • a patch function according to the prior art can be used.
  • Such embodiments have the advantage that the patch functionality according to the invention can be implemented in a completely customary Java Card module.
  • the smart card module 10 is set up to receive a plurality of applications-in FIG. 1 by way of example only one application 42-in the non-volatile rewritable memory 22.
  • each application 42 is embodied as a Java Card Applet and derived from the class javacard.framei ⁇ ork.Applet.
  • Each application 42 has several methods, which are indicated in Fig. 1 by horizontal subdivisions.
  • an installation routine 44 and a processing routine 46 are included in each application 42.
  • the installation routine 44 in the present exemplary embodiment is a method with the name "install”, which is called in accordance with the Java Card standard after loading the application 42 in order to generate an instance of the application 42 and to register it in the runtime environment.
  • APDU Application Protocol Data Unit
  • the application has 42 other routines - eg methods with the names "select” and “deselect” - which, however, are of no relevance here.
  • the loader 38 (installer) is used to load other applications in the smart card module 10.
  • the loader 38 is a known installer according to the Java Card standard, as described for example in the above-mentioned document "Runtime Environment Specification Java Card TM Platform, version 2.2.2 ". Relative to its environment, the loader 38 behaves like an application executed by the smartcard module 10, even though it is part of the system programs 26 in the wording of the present document.
  • CAP Converted Applet
  • To load the application first the loading program 38 is selected. If, as usual, commands according to the GP (Global Platform) specification are used, the loading is then performed by the command APDU "INSTALL FOR LOAD", followed by one or more command APDUs "LOAD”.
  • the new program package 48 has been successfully loaded into the non-volatile rewritable memory 22, it is installed by means of the command APDU "INSTALL FOR INSTALL".
  • the installation routine-in the present embodiment the "instaW method" -of the new application is executed.On the basis of another standard, different-looking commands may occur instead of the GP-conforming commands mentioned, but they have the same function.
  • the just outlined process for reloading applications into the smart card module 10 is known as such from the / ⁇ u ⁇ -C ⁇ rd standard. In the exemplary embodiments described here, however, this charging process is used to load a patch - ie a "patch" for a system or application program already in the smart card module 10 - into the smart card module 10 and to install it there.
  • a pseudo-application 50 is provided according to the invention.
  • the pseudo-application 50 shown in FIG. 2 corresponds in its structure to a regular application 42.
  • the pseudo-application 50 has an installation routine 52 embodied as an "instaZ /" method and a processing routine 54 designed as a "process" method.
  • pseudo-application 50 contains patch data 56 which, in the present exemplary embodiment, are subdivided into a signature 58, an identifier 60 and the actual patch 62.
  • the patch 62 is useful in encrypted form.
  • the encryption is done using a symmetric method.
  • the keys required for decrypting a patch 62 can then be advantageously introduced into the non-volatile memory 22 in advance together with the patch routine 40.
  • the signature 58 covers both the identifier 60 and the patch 62 and represents a safeguard against unauthorized manipulation. It is also readily possible to provide a plurality of signatures instead of a single signature 58 which, for example, can be assigned to different users of the system programs 26 or the runtime environment 30 can.
  • the pseudo-application 50 is not set up for processing command APDUs.
  • the processing routine 54 of the pseudo-application 50 is therefore present only in form and consists only of a command that triggers an exception handling.
  • this command may read as follows:
  • the installation routine 52 carries out the actual task of the pseudo-application 50. This object is in the present embodiment in that the installation routine 52, as soon as it is called in the course of loading the pseudo-application 50 in the smart card module 10, their- On the other hand, calls the patch routine 40 and her the patch data 56 - or a reference to the patch data 56 - passes. This process is indicated in Fig. 2 by the dashed arrows.
  • the patch routine 40 then verifies the patch data 56. In doing so, it ensures by means of suitable methods that the patch data 56 is in order and all prerequisites for the installation of the patch 62 are met. In particular, the patch routine 40 checks the correctness of the signature 58 and the validity of the identifier 60 and decrypts the patch 62 if it is encrypted. If checks and decryption are successful, the patch routine 40 installs the patch 62 in the non-volatile memory 22 of the smart card module 10. This is shown in Fig. 2 by the dotted arrow. The memory area in which the patch 62 is to be installed may be indicated, for example, in the identifier 60 or in the patch 62 or in other components of the patch data 56 (not shown in FIG. 2).
  • FIG. 3 illustrates in more detail the steps of installing patch 62 in smart card module 10, described briefly above.
  • step 70 The process is initiated in step 70 by loading program 38 receiving the command "INSTALL FOR LOAD".
  • the program package 48 with the pseudo-application 50 is then transferred to the smart card module 10 with one or more "LOAD" commands.
  • the pseudo-application 50 is applied in the non-volatile rewritable memory 22.
  • the loader program 38 receives the command APDU "INSTALL FOR LOAD".
  • the load program 38 processes this command APDU and calls the installation routine 52 - ie the "zns £ ⁇ //" method of the pseudo-application 50.
  • the installation routine 52 invokes the patch routine 40 in step 74 and notifies the patch 62 by the installation routine 52 passing a reference to the patch data 56 to the patch routine 40.
  • the installation routine 52 of the pseudo-application 50 does not need to carry out the usual registration in regular applications (calling the applet. Register method). In contrast to regular applications, the pseudo-application 50 does not need to be selectable, and an entry of the pseudo-application 50 into the registry file (registry) of the system programs 26 is therefore not necessary.
  • the patch routine 40 first checks the correctness of the signature 58 or signatures in step 76. Here, both the identifier 60 and the actual patch 62 are verified. If it is encrypted, the patch 62 is decrypted first. If the signature check was successful in step 76, the patch routine 40 checks the identifier 60 in step 78.
  • the identifier 60 expediently contains a sequential number of all patches for the smart card module 10, also referred to as patch level.
  • step 78 it is then checked whether the current Number of the patch 62 to be installed is an allowable number with respect to the series of numbers of the already existing patches; In the simplest version, it can be checked, for example, whether the sequence number is equal to the next highest number of the last patch installed in the smart card module 10. If the number is permissible, eg if there is a complete chain of patches, the current patch 62 can be installed. If one of the two test steps 76 and 78 fails, the process is aborted.
  • the smart card module 10 has a separate patch area in the non-volatile rewritable memory 22 into which the patch 62 is written and activated by appropriately setting jump targets.
  • other techniques may be used to perform the actual patching process.
  • the pseudo-application 50 is deleted in an optional step 82 and thus freed the space occupied by the pseudo-application 50.
  • the pseudo-application 50 is deleted in an optional step 82 and thus freed the space occupied by the pseudo-application 50.
  • Java Card standard deletion program Applet Deletion Manager
  • embodiments are also provided in which the pseudo-application 50 is not deleted.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Business, Economics & Management (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Stored Programmes (AREA)

Abstract

Bei einem Verfahren zum Installieren eines Patch (62) in einem Smartcard-Modul wird ein Ladeprogramm (38) zum Laden einer Pseudo-Applikation (50), die den Patch (62) enthält, in das Smartcard-Modul genutzt. Eine in der Pseudo-Applikation (50) enthaltene Installationsroutine (52) wird aufgerufen, die ihrerseits den Patch (62) einer in Systemprogrammen (26) des Smartcard-Moduls enthaltenen Patchroutine (40) mitteilt, um den Patch (62) an einen Ort außerhalb der Pseudo-Applikation (50) zu installieren. Die erfindungsgemäße Technik kann zum Installieren des Patch (62) im Feld verwendet werden und erfordert nur geringen Aufwand und nur geringe Änderungen an bestehenden Komponenten und Strukturen.

Description

Installieren eines Patch in einem Smartcard-Modul
Die Erfindung betrifft allgemein das technische Gebiet der Installation von Patches in Smartcard-Modulen. Ein Smartcard-Modul in der Wortwahl des vorliegenden Dokuments kann beispielsweise die Bauform einer Chipkarte oder eines kompakten Chipmoduls aufweisen.
Smartcard-Module werden für eine Vielzahl von Anwendungen eingesetzt. Neben den ursprünglich vorherrschenden Ausgestaltungen als Chipkarten oder einsteckbare Chipmodule - z.B. SIMs für Mobiltelefone - werden in zunehmendem Umfang Smartcard-Module entwickelt, die zum festen Einbau in Geräte vorgesehen sind. Solche eingebaute Module können beispielsweise als NFC-Module (NFC = Near Field Communications) ausgestaltet sein, die die Funktion einer Smartcard mit einer drahtlosen Kommunikationsschnittstelle kurzer Reichweite kombinieren. Nach der Herstellung eines Gerätes mit fest eingebautem Smartcard-Modul - z.B. eines Mobil telefons mit eingelötetem Smartcard-Modul - ist das Smartcard-Modul nicht mehr oder nur noch mit erheblichem Aufwand von dem Gerät trennbar.
Viele Ausgestaltungen von Smartcard-Modulen weisen Systemprogramme auf, die eine Laufzeitumgebung zum Ausführen von Applikationen und ein Ladeprogramm zum Laden von Applikationen in das Smartcard-Modul bereitstellen. Derartige Smartcard-Module sind z.B. unter der Marke Java Card bekannt. Das Dokument "Runtime Environment Specification Java Card™ Platform, Version 2.2.2", März 2006, herausgegeben von der Firma Sun Microsystems, Inc., Santa Clara, USA, beschreibt die Laufzeitumgebung einschließlich des Ladeprogramms bei Java-Card-Modulen.
Viele Smartcard-Module enthalten umfangreiche und komplexe Software. Dies gilt insbesondere für Java-Card-Module, weil diese relativ aufwändig sind und daher primär für anspruchsvolle Aufgaben eingesetzt werden. Auch wenn die in einem Smartcard-Modul enthaltene Software mit großer Sorgfalt erstellt wird, sind Fehler nicht völlig auszuschließen. Um derartige Fehler vor der Auslieferung des Smartcard-Moduls zu korrigieren, ist es bekannt, im Zuge der Komplettierung oder der Initialisierung des Smartcard- Moduls Patches in das Modul einzubringen. Gemäß dem allgemein üblichen Sprachgebrauch wird hierbei unter einem Patch oder "Flicken" Programmcode verstanden, der kein eigenständiges System- oder Anwendungsprogramm darstellt, sondern zur Modifikation eines bestehenden Programms - insbesondere zur Fehlerkorrektur oder Funktionserweiterung - dient.
Die gerade erwähnte Patch-Möglichkeit ist jedoch nach der Komplettierung bzw. Initialisierung des Smartcard-Moduls nicht mehr nutzbar. Wird ein schwerwiegender Fehler erst nach diesem Zeitpunkt entdeckt, so kann ein Austausch des Smartcard-Moduls erforderlich werden. Bei einem Smartcard- Modul in Chipkarten-Bauform besteht das Problem weniger in den Kosten für eine neue Chipkarte, sondern vielmehr in dem logistischen Aufwand, der entsteht, wenn sich die Chipkarte bereits beim Endverbraucher befindet. Handelt es sich dagegen um ein fest in ein Gerät eingebautes Smartcard- Modul wie z.B. ein NFC-Modul, so sind möglicherweise viele bereits produzierte Geräte unbrauchbar oder in ihrer Funktion stark eingeschränkt. Je nach dem Wert der Geräte kann dadurch großer Schaden entstehen.
Prinzipiell könnten natürlich eine neue Generation von Smartcard-Modulen und ein speziell angepasstes Hintergrundsystem entwickelt werden, die eine Funktion zum Patchen der Smartcard-Module im Feld bereitstellen. Diese Vorgehensweise wäre jedoch technisch komplex, teuer und zeitaufwändig. Es besteht daher Bedarf nach einer Patch-Möglichkeit, die sich mit möglichst wenig Aufwand und möglichst geringen Änderungen bei heute üblichen Smartcard-Modulen - z.B. Java-Card-Modulen - und heute üblichen Hintergrundsystemen einsetzen lässt. Das US-Patent 6,202,208 offenbart eine Technik zum Patchen eines von einer Java™ Virtual Machine - also nicht einer Java Card Virtual Machine - üblicherweise auf einem PC oder jedenfalls einem hinsichtlich seiner Hardware-Ressourcen nicht beschränkten System ausgeführten Programms. Beim Einspielen eines Patch wird mindestens ein Eintrag in einer
Methodentabelle des Programms geändert, so daß der geänderte Eintrag auf einen durch den Patch bereitgestellten Methodenkörper (method body) verweist. Auf diese Weise kann das Programm während des laufenden Betriebs geändert werden. Diese Funktionalität ist z.B. für Telekommunikations- Vermittlungsanlagen wichtig, bei denen möglichst keine Ausfallzeiten auftreten sollen.
Die Erfindung hat die Aufgabe, eine Technik zur Installation eines Patch in einem Smartcard-Modul auch nach der Komplettierung bzw. Initialisierung des Smartcard-Moduls bereitzustellen, die nur geringen Aufwand und nur geringe Änderungen an bestehenden Komponenten und Strukturen erfordert.
Erfindungsgemäß wird diese Aufgabe durch ein Verfahren mit den Merk- malen des Anspruchs 1, ein Verfahren mit den Merkmalen des Anspruchs 11 und ein Smartcard-Modul mit den Merkmalen des Anspruchs 12 gelöst. Die abhängigen Ansprüche betreffen optionale Merkmale einiger Ausgestaltungen der Erfindung.
Die Erfindung geht von der Grundidee aus, die an sich bekannte Funktion des Smartcard-Moduls zum Laden von Applikationen auch zum Einbringen des Patch in das Smartcard-Modul zu verwenden. Hierzu ist erfindungsgemäß vorgesehen, mittels des Ladeprogramms eine Pseudo-Applikation, die den Patch enthält, in das Smartcard-Modul zu laden, und eine in der Pseudo-Applikation enthaltene Installationsroutine aufzurufen, die ihrerseits den Patch einer in den Systemprogrammen enthaltenen Patchroutine mit- teilt, um den Patch an einen Ort außerhalb der Pseudo- Applikation zu installieren.
Das erfindungsgemäße "Verpacken" des Patch in die Pseudo- Applikation hat den erheblichen Vorteil, daß an sich bekannte Funktionen und Strukturen, wie sie z.B. bei Smartcard-Modulen nach dem Java-Card-Standard üblich sind, zum Erzielen der Patch-Funktionalität genutzt werden. So braucht z.B. in manchen Ausgestaltungen lediglich die Patchroutine neu entwickelt zu werden, und auch diese Patchroutine kann sich auf bereits bestehende Funk- tionen zum Einbringen von Patches während der Initialisierung und/ oder Komplettierung des Smartcard-Moduls stützen. Das eigentlich zum Laden regulärer Applikationen vorgesehene Ladeprogramm kann in manchen Ausgestaltungen ohne jede Veränderung auch zum Laden der Pseudo- Applikation, die den Patch enthält, eingesetzt werden.
Das erfindungsgemäße Verfahren ist für die Außenwelt transparent. Der in die Pseudo- Applikation verpackte Patch kann daher auf beliebige Weise - z.B. in einem OTA-Ladevorgang (OTA = over the αir) in das Smartcard- Modul eingebracht werden.
In manchen Ausgestaltungen ist der Patch für mindestens eines der Systemprogramme des Smartcard-Moduls vorgesehen. Der Patch kann beispielsweise in einen gesonderten Patchbereich in einem nicht-flüchtigen überschreibbaren Speicher des Smartcard-Moduls eingeschrieben werden.
In manchen Ausführungsformen ist der Patch durch eine Signatur abgesichert. Alternativ oder zusätzlich kann ein Identifikator vorgesehen sein, der sicherstellt, daß nur eine ununterbrochene Folge aufeinander aufbauender Patches installiert werden kann. Allgemein können beliebige kryptographische Prüfsummen und Authentisierungen verwendet werden, um das Verfahren gegen eine unautorisierte Veränderung der im Smartcard- Modul gespeicherten Programme abzusichern.
In den Ausführungsbeispielen des vorliegenden Dokuments werden haupt- sächlich Smartcard-Module nach dem /cuα-Cαrd-Standard beschrieben. Die Erfindung ist jedoch auch zur Verwendung bei anderen Smartcard-Modulen geeignet, die ähnliche Strukturen aufweisen. Dies können beispielsweise Smartcard-Module nach dem .NET-Standard sein.
Weitere Merkmale, Vorteile und Aufgaben der Erfindung gehen aus der folgenden genauen Beschreibung eines Ausführungsbeispiels und mehrerer Ausführungsalternativen hervor. Es wird auf die schematischen Zeichnungen verwiesen, in denen zeigen:
Fig. 1 ein Blockdiagramm mit Funktionseinheiten eines Smartcard-Moduls nach einem Ausführungsbeispiel der Erfindung,
Fig. 2 eine Darstellung der Systemprogramme und der Pseudo- Applikation im Speicher des Smartcard-Moduls nach Fig. 1 bei der Installation des Patch, und
Fig. 3 ein Ablaufdiagramm eines Verfahrens zur Installation eines Patch in dem Smartcard-Modul nach Fig. 1.
Das in Fig. 1 dargestellte Smartcard-Modul 10 ist im vorliegenden Ausführungsbeispiel als Chipmodul zum Einlöten in ein Host-Gerät - z.B. ein Mobil telefon - ausgestaltet. Das Smartcard-Modul 10 weist einen Prozessor 12, einen Speicher 14, eine Host-Schnittstelle 16 und eine Funk-Schnittstelle 18 auf. Hierbei wird die Host-Schnittstelle 16 zur leitungsgebundenen Kom- munikation mit dem Host-Gerät verwendet, während die Funk-Schnittstelle 18 zur drahtlosen Kommunikation über kurze Distanzen (NFC = Near Field Communications) mit einem externen Terminal dient.
Der Speicher 14 ist in mehrere Speicherfelder unterteilt. Im vorliegenden Ausführungsbeispiel sind als Speicherfelder ein als ROM ausgebildeter Festwertspeicher 20, ein als EEPROM ausgebildeter, nicht-flüchtiger überschreibbarer Speicher 22 und ein als RAM ausgebildeter Arbeitsspeicher 24 vorgesehen.
Das Smartcard-Modul 10 ist gemäß dem Java- Card-Standard ausgestaltet. Es weist umfangreiche Systemprogramme 26 auf, die sich teils im Festwertspeicher 20 und teils im nicht-flüchtigen überschreibbaren Speicher 22 befinden sowie auf Daten im Arbeitsspeicher 24 zugreifen. Die Systemprogramme 26 bilden ein Betriebssystem 28, eine Laufzeitumgebung 30 und einen Satz von Hilfsprogrammen 32. Das Betriebssystem 28 stellt hardwarenahe Funktionen bereit, die von der Laufzeitumgebung 30 und den Hilfsprogrammen 32 genutzt werden. Die Laufzeitumgebung 30 weist eine virtuelle Maschine 34 auf, die im vorliegenden Ausführungsbeispiel als JCVM (Java Card Virtual Machine) ausgestaltet ist. Ferner ist als Teil der Laufzeitumgebung 30 eine Klassenbibliothek 36 vorgesehen, die Anwendungsprogrammierschnittstellen bereitstellt.
In den Systemprogrammen 26 sind ein Ladeprogramm 38 {Installer) und eine Patchroutine 40 enthalten, deren Arbeitsweise später noch genau beschrie- ben wird. In dem Ausführungsbeispiel gemäß Fig. 1 ist die Patchroutine 40 Bestandteil der Klassenbibliothek 36, während das Ladeprogramm 38 als eines der Hilfsprogramme 32 ausgestaltet ist. In Ausführungsalternativen können das Ladeprogramm 38 und/ oder die Patchroutine 40 in anderen Gliederungseinheiten der Systemprogramme 26 enthalten sein. Bis auf die Patchroutine 40 sind sämtliche Systemprogramme 26 übliche Komponenten eines Java-Card-Moduls. Die Patchroutine 40 kann schon bei der Herstellung des Smartcard-Moduls 10 vorgesehen sein. Es sind jedoch auch Ausgestaltungen möglich, bei denen die Patchroutine 40 erst zu einem späteren Zeitpunkt - z.B. bei der Komplettierung oder Initialisierung des Smartcard-Moduls 10 - in den nicht-flüchtigen überschreibbaren Speicher 22 eingebracht wird. Hierzu kann beispielsweise eine Patchfunktion nach dem Stand der Technik verwendet werden. Derartige Ausgestaltungen haben den Vorteil, daß die erfindungsgemäße Patch-Funktionalität in einem völlig üblichen Java-Card-Modul implementiert werden kann.
Das Smartcard-Modul 10 ist dazu eingerichtet, mehrere Applikationen - in Fig. 1 ist beispielhaft nur eine Applikation 42 gezeigt - im nicht-flüchtigen überschreibbaren Speicher 22 aufzunehmen. Im vorliegenden Ausführungs- beispiel ist jede Applikation 42 als Java Card Applet ausgebildet und aus der Klasse javacard.frameiυork.Applet abgeleitet. Jede Applikation 42 weist mehrere Methoden auf, die in Fig. 1 durch horizontale Unterteilungen angedeutet sind. Insbesondere sind in jeder Applikation 42 eine Installationsroutine 44 und eine Verarbeitungsroutine 46 enthalten.
Die Installationsroutine 44 ist im vorliegenden Ausführungsbeispiel eine Methode mit dem Namen "install", die gemäß dem Java-Card-Standard nach dem Laden der Applikation 42 aufgerufen wird, um eine Instanz der Applikation 42 zu erzeugen und bei der Laufzeitumgebung zu registrieren. Die als Methode mit dem Namen "process" ausgestaltete Verarbeitungsroutine 46 interpretiert und bearbeitet eingehende Kommando- APDUs (APDU = Application Protocol Data Unit), die an die Applikation 42 gerichtet sind. In der Regel weist die Applikation 42 weitere Routinen - z.B. Methoden mit den Namen "select" und "deselect" - auf, die hier jedoch nicht weiter von Belang sind. Das Ladeprogramm 38 (Installer) dient zum Laden weiterer Applikationen in das Smartcard-Modul 10. In den vorliegenden Ausführungsbeispielen ist das Ladeprogramm 38 ein an sich bekannter Installer gemäß dem Java-Card- Standard, wie er z.B. in dem eingangs erwähnten Dokument "Runtime Environment Specification Java Card™ Platform, Version 2.2.2" beschrieben ist. Gegenüber seiner Umgebung verhält sich das Ladeprogramm 38 wie eine vom Smartcard-Modul 10 ausgeführte Applikation, auch wenn es in der Wortwahl des vorliegenden Dokuments Teil der Systemprogramme 26 ist.
Das Ladeprogramm 38 erhält eine in das Smartcard-Modul 10 zu ladende Applikation in Form eines Programmpakets 48 im CAP-Format (CAP = Converted Applet). Zum Laden der Applikation wird zunächst das Ladeprogramm 38 selektiert. Werden - wie verbreitet üblich - Kommandos gemäß der GP (Global Platform) Spezifikation genutzt, erfolgt der Ladevorgang dann durch die Kommando- APDU "INSTALL FOR LOAD", gefolgt von einer oder mehrerer Kommando- APDUs "LOAD". Nachdem das neue Programmpaket 48 erfolgreich in den nicht-flüchtigen überschreibbaren Speicher 22 geladen wurde, wird es mittels der Kommando- APDU "INSTALL FOR INSTALL" installiert. Hierbei wird unter anderem die Installationsroutine - im vorliegenden Ausführungsbeispiel die "instaW-Methode - der neuen Applikation ausgeführt. Bei Zugrundelegung eines anderen Standards können an Stelle der genannten GP-konformen Kommandos auch anders aussehende Kommandos treten, die aber diegleiche Funktion haben.
Der gerade kurz umrissene Vorgang zum Nachladen von Applikationen in das Smartcard-Modul 10 ist als solcher aus dem /αuα-Cαrd-Standard bekannt. In den hier beschriebenen Ausführungsbeispielen wird dieser Ladevorgang jedoch genutzt, um einen Patch - also einen "Flicken" für ein bereits im Smartcard-Modul 10 befindliches System- oder Anwendungsprogramm - in das Smartcard-Modul 10 zu laden und dort zu installieren. Hierzu ist erfindungsgemäß die Verwendung einer Pseudo- Applikation 50 vorgesehen. Die in Fig. 2 gezeigte Pseudo- Applikation 50 entspricht in ihrer Struktur einer regulären Applikation 42. Insbesondere weist die Pseudo- Applikation 50 eine als "instaZ/"-Methode ausgestaltete Installationsroutine 52 und eine als "process "-Methode ausgestaltete Verarbeitungsroutine 54 auf. Ferner sind in der Pseudo- Applikation 50 Patchdaten 56 enthalten, die im vorliegenden Ausführungsbeispiel in eine Signatur 58, einen Identifikator 60 und den eigentlichen Patch 62 gegliedert sind. Der Patch 62 liegt zweckmäßig in verschlüsselter Form vor. Vorzugsweise erfolgt die Verschlüsselung unter Verwendung eines symmetrischen Verfahrens. Die zur Entschlüsselung eines Patches 62 benötigten Schlüssel können dann vorab zusammen mit der Patchroutine 40 zweckmäßig in den nicht-flüchtigen Speicher 22 eingebracht werden. Die Signatur 58 deckt sowohl den Identifikator 60 als auch den Patch 62 ab und stellt eine Sicherung gegen unerlaubte Manipulationen dar. Ohne weiteres können statt einer einzelnen Signatur 58 auch mehrere Signaturen vorgesehen sein, die z.B. verschiedenen Nutzern der Systemprogramme 26 oder der Laufzeitumgebung 30 zugeordnet sein können.
Im Unterschied zu einer regulären Applikation 42 ist die Pseudo- Applikation 50 nicht zur Verarbeitung von Kommando- APDUs eingerichtet. Die Verarbeitungsroutine 54 der Pseudo- Applikation 50 ist daher nur der Form nach vorhanden und besteht lediglich aus einem Befehl, der eine Ausnahmebehandlung auslöst. Dieser Befehl kann beispielsweise wie folgt lauten:
ISOException.throwIt(ISO7816.SW_FUNC_NOT_SUPPORTED);
Die Installationsroutine 52 führt die eigentliche Aufgabe der Pseudo- Applikation 50 aus. Diese Aufgabe besteht im vorliegenden Ausführungsbeispiel darin, daß die Installationsroutine 52, sobald sie im Zuge des Ladens der Pseudo- Applikation 50 in das Smartcard-Modul 10 aufgerufen wird, ihrer- seits die Patchroutine 40 aufruft und ihr die Patchdaten 56 - beziehungsweise einen Verweis auf die Patchdaten 56 - übergibt. Dieser Vorgang ist in Fig. 2 durch die gestrichelten Pfeile angedeutet.
Die Patchroutine 40 verifiziert daraufhin die Patchdaten 56. Hierbei stellt sie mittels geeigneter Verfahren sicher, daß die Patchdaten 56 in Ordnung und alle Voraussetzungen für die Installation des Patches 62 erfüllt sind. Insbesondere überprüft die Patchroutine 40 die Korrektheit der Signatur 58 und die Gültigkeit des Identifikators 60 und entschlüsselt den Patch 62, wenn dieser verschlüsselt vorliegt. Falls Überprüfungen und Entschlüsselung erfolgreich verlaufen, installiert die Patchroutine 40 den Patch 62 in dem nicht-flüchtigen Speicher 22 des Smartcard-Moduls 10. Dies ist in Fig. 2 durch den gepunkteten Pfeil dargestellt. Der Speicherbereich, in dem der Patch 62 installiert werden soll, kann beispielsweise in dem Identifikator 60 oder im Patch 62 oder in anderen - in Fig. 2 nicht gezeigten - Komponenten der Patchdaten 56 angegeben sein.
Die gerade beschriebene Aufteilung der Funktionen zwischen der Installationsroutine 52 und der Patchroutine 40 stellt sicher, daß das sicherheits- kritische Einspielen des Patch 62 in das Smartcard-Modul 10 nur nach einer erfolgreichen Verifikation durch die Patchroutine 40 erfolgt. Es versteht sich, daß die mit dem Einspielen des Patch 62 zusammenhängenden Schritte in Ausführungsalternativen anders zwischen der Installationsroutine 52 und der Patchroutine 40 - sowie gegebenenfalls weiteren Routinen - aufgeteilt werden können. Die Verwendung einer in den Systemprogrammen 26 enthaltenen Patchroutine 40 ist in der Regel erforderlich, um den Patch 62 außerhalb der Pseudo- Applikation 50 - insbesondere in den Systemprogrammen 26 oder in manchen Ausgestaltungen auch in anderen Applikationen - installieren zu können. Fig. 3 stellt die gerade kurz beschriebenen Schritte des Installierens des Patch 62 im Smartcard-Modul 10 ausführlicher dar. Der Ablauf wird in Schritt 70 dadurch ausgelöst, daß das Ladeprogramm 38 die Kommando- APDU "INSTALL FOR LOAD" erhält. Das Programmpaket 48 mit der Pseudo-App- likation 50 wird daraufhin mit einem oder mehreren "LOAD"-Kommandos in das Smartcard-Modul 10 übertragen. Hierbei wird die Pseudo- Applikation 50 im nichtflüchtigen überschreibbaren Speicher 22 angelegt.
Im folgenden Schritt 72 erhält das Ladeprogramm.38 die Kommando- APDU "INSTALL FOR LOAD". Das Ladeprogramm 38 bearbeitet diese Kommando- APDU und ruft dabei die Installationsroutine 52 - also die "zns£α//"-Methode der Pseudo- Applikation 50 - auf. Die Installationsroutine 52 ruft ihrerseits in Schritt 74 die Patchroutine 40 auf und teilt dieser den Patch 62 mit, indem die Installationsroutine 52 einen Verweis auf die Patchdaten 56 an die Patch- routine 40 übergibt.
Die Installationsroutine 52 der Pseudo- Applikation 50 braucht die bei regulären Applikationen übliche Registrierung (Aufruf der Methode Applet. register) nicht auszuführen. Im Gegensatz zu regulären Applikationen braucht die Pseudo- Applikation 50 nämlich nicht selektierbar zu sein, und ein Eintrag der Pseudo-Applikation 50 in die Registrierungsdatei (Registry) der Systemprogramme 26 ist daher nicht erforderlich.
Nach ihrem Aufruf prüft die Patchroutine 40 zunächst in Schritt 76 die Korrektheit der Signatur 58 bzw. Signaturen. Hierbei werden sowohl der Identifikator 60 als auch der eigentliche Patch 62 verifiziert. Sofern er verschlüsselt vorliegt, wird der Patch 62 dazu zunächst entschlüsselt. Wenn die Signaturprüfung in Schritt 76 erfolgreich war, überprüft die Patchroutine 40 in Schritt 78 den Identifikator 60. Der Identifikator 60 enthält zweckmäßig eine auch als Patchlevel bezeichnete laufende Nummer aller Patches für das Smartcard-Modul 10. In Schritt 78 wird dann geprüft, ob die laufende Nummer des gerade zur Installation vorgesehenen Patch 62 eine zulässige Nummer im Hinblick auf die Reihe der Nummern der bereits vorhandenen Patches ist; in einfachster Ausführung kann z.B. geprüft werden, ob die laufende Nummer gleich der nächst höheren Nummer des letzen im Smart- card-Modul 10 installierten Patch ist. Ist die Nummer zulässig, liegt z.B. eine lückenlose Kette von Patches vor, kann der aktuelle Patch 62 installiert werden. Schlägt einer der beiden Prüfschritte 76 und 78 fehl, wird der Vorgang abgebrochen.
Installation und Aktivierung des Patch 62 erfolgen in Schritt 80. Hierzu kann ein an sich bekanntes Verfahren eingesetzt werden. In vielen Ausführungsformen weist das Smartcard-Modul 10 einen gesonderten Patchbereich im nicht-flüchtigen überschreibbaren Speicher 22 auf, in den der Patch 62 eingeschrieben und durch geeignetes Setzen von Sprungzielen aktiviert wird. Es können jedoch auch andere Techniken zum Ausführen des eigentlichen Patch- Vorgangs eingesetzt werden.
Nach einer erfolgreichen Installation des Patch in Schritt 80 wird in einem optionalen Schritt 82 die Pseudo- Applikation 50 gelöscht und somit der von der Pseudo- Applikation 50 belegte Speicherplatz freigegeben. Hierzu wird das gemäß dem Java-Card-Standard vorgesehene Löschprogramm (Applet Deletion Manager) eingesetzt. Es sind jedoch auch Ausgestaltungen vorgesehen, bei denen die Pseudo- Applikation 50 nicht gelöscht wird.
Die erfolgreiche Installation des Patch 62 kann nun an das Hintergrundsystem in einer Antwort- APDU zurückgemeldet werden.
Es versteht sich, daß die hier beschriebenen Ausführungsformen und Ausführungsvarianten lediglich als Beispiele zu sehen sind. Weitere Abwand- lungen und Kombinationen der hier beschriebenen Merkmale sind für den Fachmann unmittelbar ersichtlich.

Claims

P a t e n t a n s p r ü c h e
1. Verfahren zum Installieren eines Patch (62) in einem Smartcard- Modul (10), wobei das Smartcard-Modul (10) Systemprogramme
(26) aufweist, die eine Laufzeitumgebung (30) zum Ausführen von Applikationen (42, 50) in dem Smartcard-Modul (10) und ein Ladeprogramm (38) zum Laden von Applikationen (42, 50) in das Smartcard-Modul (10) bereitstellen, mit den Schritten: - Nutzen des Ladeprogramms (38) zum Laden einer Pseudo¬
Applikation (50), die den Patch (62) enthält, in das Smartcard- Modul (10), und
Aufrufen einer in der Pseudo- Applikation (50) enthaltenen Installationsroutine (52), die ihrerseits den Patch (62) einer in den Systemprogrammen (26) enthaltenen Patchroutine (40) mitteilt, um den Patch (62) an einen Ort außerhalb der Pseudo- Applikation (50) zu installieren.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß die Patchroutine (40) den Patch (62) in mindestens eines der Systemprogramme (26) installiert.
3. Verfahren nach Anspruch 1 oder Anspruch 2, dadurch gekennzeichnet, daß die Systemprogramme (26) ein Betriebssystem (28), eine virtuelle Maschine (34) und eine Klassenbibliothek (36) aufweisen.
4. Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, daß das Smartcard-Modul (10) einen nicht-flüchtigen überschreibbaren Speicher (22) aufweist, und daß die Patchroutine (40) den Patch (62) in einen Bereich des nicht-flüchtigen überschreibbaren Speicher (22) einschreibt.
5. Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, daß jede in das Smartcard-Modul (10) geladene Applikation (42, 50) eine Installationsroutine (44, 52) bereitstellt, die beim Laden der Applikation (42, 50) aufgerufen wird, und daß die Installationsroutine (52) der Pseudo- Applikation (50) in gleicher
Weise wie die Installationsroutine (44) einer regulären Applikation (42) aufgerufen wird.
6. Verfahren nach einem der Ansprüche 1 bis 5, dadurch gekenn- zeichnet, daß dem Patch (62) ein Identifikator (60) zugeordnet ist, und daß der Patch (62) nur dann installiert wird, wenn der Identifikator (60) angibt, daß der unmittelbar vorhergehende Patch bereits installiert wurde.
7. Verfahren nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, daß dem Patch (62) eine Signatur (58) zugeordnet ist, und daß der Patch (62) nur nach einer erfolgreichen Signaturprüfung (76) installiert wird.
8. Verfahren nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, daß der Patch (62) in verschlüsselter Form bereitgestellt wird.
9. Verfahren nach einem der Anspruch 6 bis Anspruch 8, dadurch gekennzeichnet, daß die Signatur (58), der Identifikator (60) und der Patch (62) in der Pseudo- Applikation (50) enthalten sind.
10. Verfahren nach einem der Ansprüche 1 bis 9, dadurch gekennzeichnet, daß das Smartcard-Modul (10) als Java Card ausgestaltet ist.
11. Verfahren nach Anspruch 10, dadurch gekennzeichnet, daß die Pseudo- Applikation (50) als Programmpaket (48) im CAP-Format in das Smartcard-Modul (10) geladen wird.
12. Verfahren zum Komplettieren und/ oder Initialisieren eines
Smartcard-Moduls (10), dadurch gekennzeichnet, daß in das Smartcard-Modul (10) eine Patchroutine (40) eingebracht wird, die dazu eingerichtet ist, in einem Verfahren nach einem der Ansprüche 1 bis 11 aufgerufen und zum Installieren eines Patch (62) verwendet zu werden.
13. Smartcard-Modul (10) mit einem Prozessor (12), einem Speicher (14) und einer Host-Schnittstelle (16), das zur Ausführung eines Verfahrens nach einem der Ansprüche 1 bis 10 eingerichtet ist.
14. Smartcard-Modul (10) nach Anspruch 13, dadurch gekennzeichnet, daß das Smartcard-Modul (10) als NFC-Modul ausgestaltet ist und eine Funk-Schnittstelle (18) aufweist.
EP08707129A 2007-01-24 2008-01-18 Installieren eines patch in einem smartcard-modul Ceased EP2111578A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102007003580A DE102007003580A1 (de) 2007-01-24 2007-01-24 Installieren eines Patch in einem Smartcard-Modul
PCT/EP2008/000387 WO2008089922A1 (de) 2007-01-24 2008-01-18 Installieren eines patch in einem smartcard-modul

Publications (1)

Publication Number Publication Date
EP2111578A1 true EP2111578A1 (de) 2009-10-28

Family

ID=39345199

Family Applications (1)

Application Number Title Priority Date Filing Date
EP08707129A Ceased EP2111578A1 (de) 2007-01-24 2008-01-18 Installieren eines patch in einem smartcard-modul

Country Status (4)

Country Link
US (1) US20100012732A1 (de)
EP (1) EP2111578A1 (de)
DE (1) DE102007003580A1 (de)
WO (1) WO2008089922A1 (de)

Families Citing this family (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11557163B2 (en) * 2006-08-16 2023-01-17 Isonas, Inc. System and method for integrating and adapting security control systems
DE102007041873A1 (de) 2007-09-04 2009-03-05 Giesecke & Devrient Gmbh Installieren eines Patch in einem Smartcard-Modul
US20100082702A1 (en) * 2008-09-29 2010-04-01 Honeywell International Inc. Dynamic vehicle information management
US8646059B1 (en) 2010-12-17 2014-02-04 Google Inc. Wallet application for interacting with a secure element application without a trusted server for authentication
US8621168B2 (en) 2010-12-17 2013-12-31 Google Inc. Partitioning the namespace of a contactless smart card
US9691055B2 (en) 2010-12-17 2017-06-27 Google Inc. Digital wallet
US8352749B2 (en) 2010-12-17 2013-01-08 Google Inc. Local trusted services manager for a contactless smart card
EP2466507A1 (de) * 2010-12-20 2012-06-20 Gemalto SA Verfahren zur Aktualisierung einer kodierten Datei
CN102063634B (zh) * 2010-12-24 2013-04-24 北京握奇数据系统有限公司 一种掩膜智能卡的功能扩展方法及智能卡
US8171525B1 (en) 2011-09-15 2012-05-01 Google Inc. Enabling users to select between secure service providers using a central trusted service manager
US8255687B1 (en) 2011-09-15 2012-08-28 Google Inc. Enabling users to select between secure service providers using a key escrow service
US8313036B1 (en) 2011-09-16 2012-11-20 Google Inc. Secure application directory
US8385553B1 (en) 2012-02-28 2013-02-26 Google Inc. Portable secure element
US8429409B1 (en) 2012-04-06 2013-04-23 Google Inc. Secure reset of personal and service provider information on mobile devices
EP2660721A1 (de) * 2012-05-03 2013-11-06 Gemalto SA Verfahren zum Laden einer Anwendung in einer sicheren Vorrichtung
DE102012015573A1 (de) 2012-08-07 2014-02-13 Giesecke & Devrient Gmbh Verfahren zum Aktivieren eines Betriebssystems in einem Sicherheitsmodul
CN103914351A (zh) * 2012-12-28 2014-07-09 北京中电华大电子设计有限责任公司 Java卡系统补丁实现方法
US10108409B2 (en) 2014-01-03 2018-10-23 Visa International Service Association Systems and methods for updatable applets
EP2930641B1 (de) * 2014-04-07 2019-04-03 Nxp B.V. Verfahren zur Programmierung einer Chipkarte, Computerprogrammprodukt und programmierbare Chipkarte
CN105631505B (zh) * 2014-11-07 2024-01-05 紫光同芯微电子有限公司 一种支持java卡补丁函数的智能卡
WO2016168475A1 (en) 2015-04-14 2016-10-20 Capital One Services, Llc Systems and methods for secure firmware validation
US10607220B2 (en) 2016-08-25 2020-03-31 Mastercard International Incorporated Systems and methods for consolidated message processing
CN106933536B (zh) * 2017-03-01 2019-08-27 天地融科技股份有限公司 一种智能卡的应用加载运行方法及智能卡
FR3099258B1 (fr) 2019-07-26 2022-06-24 Idemia Identity & Security France Adaptation dynamique d’un environnement d’exécution d’élément sécurisé à des profils

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6202208B1 (en) 1998-09-29 2001-03-13 Nortel Networks Limited Patching environment for modifying a Java virtual machine and method
US6390374B1 (en) * 1999-01-15 2002-05-21 Todd Carper System and method for installing/de-installing an application on a smart card
US6338435B1 (en) * 1999-01-15 2002-01-15 Todd Carper Smart card patch manager
WO2001016873A1 (en) 1999-08-31 2001-03-08 Cryptec Systems, Inc. Smart card patch manager
JP2002099312A (ja) * 2000-09-22 2002-04-05 Mitsubishi Electric Corp プログラマブルコントローラおよび制御プログラム開発支援装置
US6880084B1 (en) * 2000-09-27 2005-04-12 International Business Machines Corporation Methods, systems and computer program products for smart card product management
US20040205709A1 (en) * 2001-05-09 2004-10-14 Sun Microsystems, Inc. Method,system, and program for providing patch expressions used in determining whether to install a patch
WO2003009136A1 (en) * 2001-07-16 2003-01-30 Yuqing Ren Embedded software update system
JP3880384B2 (ja) * 2001-12-06 2007-02-14 松下電器産業株式会社 Ｉｃカード
US20060080655A1 (en) 2004-10-09 2006-04-13 Axalto Inc. System and method for post-issuance code update employing embedded native code
US7685591B2 (en) * 2004-12-20 2010-03-23 Microsoft Corporation Customizing a software application through a patch file
US20070067325A1 (en) * 2005-02-14 2007-03-22 Xsapio, Ltd. Methods and apparatus to load and run software programs in data collection devices

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2008089922A1 *

Also Published As

Publication number Publication date
WO2008089922A1 (de) 2008-07-31
DE102007003580A1 (de) 2008-07-31
US20100012732A1 (en) 2010-01-21

Similar Documents

Publication Publication Date Title
EP2111578A1 (de) Installieren eines patch in einem smartcard-modul
EP2318921B1 (de) Laden und aktualisieren einer personalisierungsbedürftigen applikation
WO2014023394A1 (de) Verfahren zum aktivieren eines betriebssystems in einem sicherheitsmodul
DE102011015711A1 (de) Aktualisierung einer Datenträgerapplikation
DE102014220616A1 (de) Verfahren zum Laden von ausführbaren Programminstruktionen in eine Chipkarte im Wirkbetrieb
EP2941697A1 (de) Verfahren zum laden einer aus mehreren komponenten bestehenden applikation in ein aus mehreren komponenten bestehenden gerätes
EP2673731B1 (de) Verfahren zur programmierung eines mobilendgeräte-chips
EP3224756B1 (de) Verfahren zum nachladen von software auf eine chipkarte durch einen nachladeautomaten
DE102012016164A1 (de) Sicherheitselement und Verfahren zur Installation von Daten in dem Sicherheitselement
DE102007041873A1 (de) Installieren eines Patch in einem Smartcard-Modul
EP3234843A1 (de) Verfahren zum bereitstellen einer sicherheitskritischen softwareapplikation auf einer computereinheit
WO2011033030A1 (de) Verfahren zum installieren und konfigurieren von applikationen auf einem portablen datenträger
DE19716015A1 (de) Einbringen von Information auf einer Chipkarte
DE102010004446A1 (de) Verfahren zum Bereitstellen eines sicheren Zählers auf einem Endgerät
EP3159821A1 (de) Prozessor-system mit applet security settings
EP3488375B1 (de) Chipset mit gesicherter firmware
DE102023102191A1 (de) Installieren eines Betriebssystems in einer Prozessoreinrichtung, insbesondere einem Sicherheitsmodul
DE102012022874A1 (de) Applikationsinstallation
DE102021000077A1 (de) Integriertes Teilnehmeridentitätsmodul mit Anti-Rollback-Mechanismus
EP2747085B1 (de) Verfahren zum Betreiben eines Sicherheitselements sowie ein solches Sicherheitselement
DE102012024250B4 (de) Verfahren zur Bereitstellung von Chips mit hoher Kopierschutzfunktion, insbesondere für digitale Authentifizierungssysteme, wie Chipkarten oder dergleichen, sowie danach hergestellte Chips
DE10323033A1 (de) Laden eines ausführbaren Programms in einen tragbaren Datenträger
DE102021005325A1 (de) Verfahren zur rechnergestützten Erzeugung eines Speicherabbilds für ein sicheres Element
EP2568377A1 (de) Programmpaketinstallation
EP1801694A2 (de) Sicherung eines tragbaren Datenträgers gegen Angriffe

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20090824

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MT NL NO PL PT RO SE SI SK TR

17Q First examination report despatched

Effective date: 20091208

DAX Request for extension of the european patent (deleted)
REG Reference to a national code

Ref country code: DE

Ref legal event code: R003

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20150115