EP3469479A1 - Ressourcenbeschränktes java card device - Google Patents

Ressourcenbeschränktes java card device

Info

Publication number
EP3469479A1
EP3469479A1 EP17732302.9A EP17732302A EP3469479A1 EP 3469479 A1 EP3469479 A1 EP 3469479A1 EP 17732302 A EP17732302 A EP 17732302A EP 3469479 A1 EP3469479 A1 EP 3469479A1
Authority
EP
European Patent Office
Prior art keywords
applet
card device
application identifier
instance
loading
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
EP17732302.9A
Other languages
English (en)
French (fr)
Inventor
Oliver Gibis
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+Devrient Mobile Security Germany GmbH
Original Assignee
Giesecke+Devrient Mobile Security Germany 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+Devrient Mobile Security Germany GmbH filed Critical Giesecke+Devrient Mobile Security Germany GmbH
Publication of EP3469479A1 publication Critical patent/EP3469479A1/de
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/61—Installation
    • 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/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • G06F21/12—Protecting executable software
    • G06F21/121—Restricting unauthorised execution of programs
    • G06F21/128—Restricting unauthorised execution of programs involving web programs, i.e. using technology especially used in internet, generally interacting with a web browser, e.g. hypertext markup language [HTML], applets, java
    • 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/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/44—Program or device authentication
    • 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/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
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/341—Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/357—Cards having a plurality of specified features
    • G06Q20/3574—Multiple applications on card

Definitions

  • the invention relates to a resource-limited card device, in particular a card device based on Java Card technology or native technology, in particular a chip card, a chip card module, or a chip card module in a housing of any desired form factor.
  • SIM Subscriber Identity Module for mobile radio.
  • the invention relates to a charging packet and a method for implementing one or more applet instances in such a resource-limited card device.
  • each applet to be installed has exactly one application identifier AID.
  • a separate applet AID must be provided for each constellation of eg applet, country and access possibility . Since each applet has only one AID, a separate separate applet is conventionally installed for each constellation of, for example, applet and deployment country and accessibility. For example, instance 1) Applet A in contact with Country X; 2) applet A in country Y contacted; 3) Applet B in country X contacted; 4) Applet B in country Y contacted; 5) Applet A in country X contactless; 6) Applet A in country Y contactless; etc.
  • the invention has for its object to provide a card device that allows a memory-saving installation of applets to be provided in different configurations. Furthermore, a method for implementing one or more applet instances in such a resource-limited card device is to be specified.
  • a card device is created which enables a memory-saving installation of applets in the card device.
  • the method is characterized in that at least one further application identifier is included in the loading packet, which refers to the same instance of the applet to be installed, and that the method comprises the further step: 4) setting up the at least one further application identifier in the card device.
  • an INSTALL command creates an applet instance and two or more applet identifiers in the card device.
  • a method according to the invention for creating an applet identifier in a card device to an instance to be installed in the card device of the applet, by means of a charging packet, according to a second option (alternative), the following steps are included. 1) Loading the charging package into the card device, wherein the charging package includes an application identifier that relates to the instance of the applet to be installed. Preferably, the loading packet contains, as usual, only a single applet identifier per applet. 2) Optionally, install the instance of the applet in the card device by applying an INSTALL command to the loading package. 3) At the instigation of the INSTALL command, set up the application identifier in the card device.
  • the method is characterized in that 4) the charging of the charging packet is carried out at least twice in succession, 5) the first time the charging packet is loaded (or when the INSTALL command is first executed) the instance of the applet is installed (ie in step 2) ) "Applet Installation") and the application identifier in the card device is set up, and 6) each time the loading package is loaded (or the INSTALL command is executed), another application identifier is set up in the card device without any further loading Instance of the applet is set up in the card device (ie in step 2 option "do not install an applet instance").
  • the loading in step 2) is optional in that only when the loading package is loaded for the first time or when the INSTALL command is used for the first time, an applet instance is installed in the device, but not during subsequent loading or INSTALL command executions.
  • the card device includes a registry
  • setting up the application identifier or the other application identifier includes storing the application identifier or the other application identifier in the registry, or the setting consists in saving in the registry.
  • a parameter is assigned to the applet.
  • different parameter values of the parameter of the applet are assigned to the application identifier and the further application identifier.
  • the parameter parameterizes the applet. This makes a configuration of the applet for the applet using the parameter. Different parameter values of the parameter lead to different configurations of the applet.
  • several configurations of the applet are realized without several applet instances being installed in the card device.
  • the applet is assigned (at least or exactly) two parameters, namely the type of contacting and the country of use. This allows you to create different configurations of the applet.
  • the following example shows a card device with two applet instances for two different applets, namely applet A and applet B, which can be parameterized with two parameters PI, P2.
  • Second parameter P2 type of contacting; possible parameter values: contact or contactless.
  • Applet A virtual credit card Domestic.
  • Applet B virtual credit card International.
  • Applet A has only one Application Identifier AID-A.
  • Applet B has two Application Identifiers AID-INT-B and AID-DOM-NFC-B.
  • AID-A Application Identifier Applet A.
  • AID-I TB Application Identifier Applet B International.
  • AID-DOM-NFC-B Application Identifier Applet B Domestic contactless.
  • FIG. 1 shows the installation of an applet instance by first sending a load packet, according to embodiments of the invention
  • FIG. 2 illustrates the personalization of an applet instance installed according to FIG. 1, according to embodiments of the invention
  • FIG. 4 shows the creation of a further applet identifier without installing another applet instance, according to embodiments of the invention
  • 5 illustrates the personalization of an installed applet instance, according to embodiments of the invention
  • Fig. 6 calling an applet with AID2 and subsequent processing of commands, according to embodiments of the invention.
  • FIG. 1 shows the installation ("INSTALL") of an applet instance by first sending a load packet, in accordance with embodiments of the invention.
  • a terminal sends APDU commands to the card device (referred to here for short as a card).
  • the terminal switches on the card device with the ICC_ON command.
  • the Card Manager is called with APDU SELECT Card Manager.
  • Authentication is performed with APDU AUTHENTICATE.
  • a loading package is loaded into the card device and an applet instance Applet Instance Object 1 is set up in the card device by creating an applet instance object with "Create new.”
  • the applet identifier AIDl of the applet is created , which is sent in the System Specific Parameters of the INSTALL, is set up in the Card Device by entering a new Card Registry Entry (entry) in the Card Registry of the Card Device using CREATE new.
  • Fig. 2 shows the personalization ("perso") of an applet instance Applet Instance Object 1 installed according to Fig. 1.
  • the applet instance With APDU SELECT and specifying the AID1, the applet instance is selected.
  • APDU AUTHENTICATE an authentication is carried out With several consecutive APDU STORE DATA, up to a LAST STORE DATA indicating the end of the personalization data, data required for personalization is stored in the card device
  • Fig. 3 shows the calling ("CALL") and use of an applet with AIDl and a subsequent processing of commands, after installing an applet of Fig. 1 and personalizing the applet of Fig. 2.
  • APDU SELECT and specifying the AIDl is The applet instance is selected
  • Various applet-specific APDU commands (“Applet Specific Commands") are sent one after the other from the terminal to the card device.
  • the card manager selects the applet instance APPLET Instance Object 1 on the card device via SELECT and sends the APD US received from the terminal to the APPLET Instance Object.
  • the applet (more precisely, the applet instance Applet Instance Object 1) carries out its (or its) intended activity.
  • FIG. 4 shows the creation of a further applet identifier by means of a new INSTALL FOR INSTALL command, without another applet instance being installed in the card device, according to embodiments of the invention.
  • a terminal sends APDU commands to the card device (referred to here for short as a card).
  • the terminal switches on the card device with the ICC_ON command.
  • the Card Manager is called with APDU SELECT Card Manager.
  • Authentication is performed with APDU AUTHENTICATE.
  • the APDU command INSTALL FOR INSTALL loads a charge package into the card device.
  • the card device detects that an applet instance Applet Instance Object 1 has already been set up in the card device and does not install another applet instance.
  • Applet Identifier AID1 of the applet is detected, which was created at the previous INSTALL FOR INSTALL when creating the applet instance that was created in the System Specific Parameters of the INSTALL.
  • FIG. 4 further illustrates an example of applying the system specific parameters to accommodate an applet identifier.
  • TAG Preferably, a value is used for TAG that is not permanently assigned, for example 4F.
  • FIG. 6 shows the call-up ("CALL") and use of an applet with a further applet identifier AID2 and a subsequent execution of commands, according to an embodiment of the invention
  • CALL call-up
  • AID2 further applet identifier
  • Various applet-specific APDU commands (“Applet Specific Commands") are sent one after the other from the terminal to the card device.
  • the card manager selects the APPLET Instance Object 1 (not 2) on the card device by means of SELECT and sends it from the terminal.
  • the applet (more precisely, the applet instance 1) carries out its (or its) intended action, initiated with the further applet identifier AID2, and based on a and the same applet instance 1.

Landscapes

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

Abstract

Die Erfindung schafft ein Card Device, eingerichtet ein Ladepaket für ein Applet entgegenzunehmen und ein INSTALL Kommandos abzuarbeiten und auf das Ladepaket anzuwenden, um ein Installieren einer Instanz (App¬ let Instance Object 1) des Applet im Card Device zu veranlassen, wobei das INSTALL Kommando eingerichtet ist, einen im Ladepaket umf assten Appli¬ cation Identifier (AID1), der sich auf die zu installierende Instanz des Applet bezieht, im Card Device einzurichten, dadurch gekennzeichnet, dass das INSTALL Kommando eingerichtet ist: - die Applet Instanz unter Berücksich¬ tigung des Application Identif iers zu installieren; und - mindestens einen weiteren Application Identifier (AID2,...), der sich auf dieselbe Instanz des Applet bezieht, im Card Device einzurichten.

Description

Ressourcen beschränktes Tava Card Device
Gebiet der Erfindung
Die Erfindung betrifft ein ressourcenbeschränktes Card Device, insbesondere ein auf der Java Card Technologie oder der native Technologie basierendes Card Device, insbesondere eine Chipkarte, ein Chipkartenmodul, oder ein Chipkartenmodul in einem Gehäuse beliebigen Formfaktors. Das Card Device kann insbesondere mit Funktionalität einer Zahlungsverkehrskarte oder mit einer SIM-Funktionalität (SIM = Subscriber Identity Module für Mobilfunk) ausgestattet sein. Weiter betrifft die Erfindung ein Ladepaket und ein Verfahren zum Implementieren einer oder mehrere Applet-Instanzen in ein solches ressourcenbeschränktes Card Device.
Stand der Technik
Ein ressourcenbeschränktes Card Device umfasst einen Mikroprozessor mit einem darauf implementierten Betriebssystem (OS) (z.B. Java Card OS oder native OS) und einen Applet-Speicher zum Implementieren von Applets. Durch im Card Device implementierte Applets werden Funktionalitäten des Card Device erzielt. Beispielsweise sind in einem Card Device mit Funktionalität einer Zahlungsverkehrskarte ein oder mehrere Zahlungsverkehrs- Applets implementiert. Für ein Card Device mit SIM-Funktionalität (SIM = Subscriber Identity Module) zur Nutzung eines mobilfunkfähigen Endgeräts in einem Mobilfunknetz sind im Card Device ein oder mehrere SIM- spezifische Applets implementiert.
Das Laden eines Applet in ein Card Device mittels APDU Kommandos ist spezifiziert im Dokument [1] Global Card Platform Specification V2.2.1, 2011, nachfolgend auch mit der offiziellen Kurzreferenz GPC_SPE_034 bezeichnet. Gemäß [1] GPC_SPE_034, Kapitel 9, speziell Kapitel 9.3, wird ein Applet in einem Card Device installiert, indem mit einem LOAD Kommando (9.3.2) ein Ladepaket für das Applet in das Card Device geladen, und mit einem INSTALL Kommando (9.3.3 ff.) mit dem Inhalt des Ladepakets eine Applet- Instanz des Applets im Card Device installiert. Gemäß [1] GPC_SPE_034 Kap. 9.3.6, Seite 84, wird beim Installieren der Applet-Instanz mittels des INSTALL Kommandos insbesondere mit einem auf Veranlassung von INSTALL anschließend ausgeführten OPEN Kommando sichergestellt, dass der Applet Identifier AID des Applet in die Registry des Java Card Device gespeichert wird. Dieser Sachverhalt ist in Fig. 9-2 (Seite 92) durch den Eintrag„install and register Application" dargestellt. Gemäß [1] GPC_SPE_034, Kap. 11 ist der Aufbau des INSTALL APDU Kommandos beschrieben ist. Gemäß Unterkapitel 11.5.2.3.2, Tabelle 11-43, wird der Application AID eines zu installierenden Applet im Datenfeld des INSTALL Kommandos übergeben, und zwar im Teilfeld„Application AID".
Gemäß [1] GPC_SPE_034 hat somit jedes zu installierende Applet genau ei- nen Application Identifier AID.
Bei einer Zahlungsverkehrskarte, die mehrere Zahlungsverkehrs- Applets beherbergt, und die in mehreren Ländern einsetzbar sein soll und/ oder die mehrere Zugangsmöglichkeiten (insbesondere kontaktlos/ kontaktbehaftet) unterstützt, muss für jede Konstellation von z.B. Applet, Land und Zugangsmöglichkeit ein eigener Applet AID vorgesehen sein. Da jedes Applet nur einen einzigen AID hat, wird herkömmlicherweise für jede Konstellation von z.B. Applet und Einsatzland und Zugangsmöglichkeit eine eigene gesonderte Applet-Instanz installiert. Beispielsweise Instanz 1) Applet A in Land X kontaktbehaftet; 2) Applet A in Land Y kontaktbehaftet; 3) Applet B in Land X kontaktbehaftet; 4) Applet B in Land Y kontaktbehaftet; 5) Applet A in Land X kontaktlos; 6) Applet A in Land Y kontaktlos; etc. Die Vielzahl von Applet-Instanzen benötigt viel Speicher. Funktionell sind dagegen alle Applet-Instanzen, die auf demselben Applet basieren, z.B. Applet B, weitge- hend identisch. In den angeführten Beispielen ist jede Konstellation durch bestimmte Parameterwerte eines oder mehrerer Parameter festgelegt. Die Parameter sind in den obigen Beispielen Kontaktierungsart zur Karte und Land. Die Parameter werte sind kontaktlos und kontaktbehaftet sowie unter- schiedliche Länder.
In [1] GPC_SPE, Kapitel 11.5.2.3.7„INSTALL Command Parameters", offenbart, dass unter den Ladeparametern („Load Parameters") eines INSTALL Kommandos, die im INSTALL Kommando umfasst sind, optional oder kon- ditional die als„System Specific Parameters" bezeichneten Parameter enthalten sein können. Diese sind systemspezifische Parameter, die für das betrachtete System spezifisch sind und abhängig vom System unterschiedliche, in gewissem Umfang frei wählbare Inhalte haben können. Aufgabe der Erfindung
Der Erfindung liegt die Aufgabe zu Grunde, ein Card Device zu schaffen, das eine speichersparende Installation von Applets ermöglicht, die in unterschiedlichen Konfigurationen vorgesehen sein sollen. Weiter soll ein Verfahren zum Implementieren einer oder mehrere Applet-Instanzen in ein solches ressourcenbeschränktes Card Device angegeben werden.
Zusammenfassung der Erfindung
Die Aufgabe wird gelöst durch ein Card Device nach Anspruch 1 und ein Ladepakte und ein Verfahren gemäß den nebengeordneten Ansprüchen. Vorteilhafte Ausgestaltungen der Erfindung sind in den abhängigen Ansprüchen angegeben.
Das erfindungsgemäße Card Device nach Anspruch 1 ist dazu eingerichtet, ein Ladepaket für ein Applet entgegenzunehmen und ein INSTALL Kom- mandos abzuarbeiten und auf das Ladepaket anzuwenden, um ein Installieren einer Instanz des Applet im Card Device zu veranlassen. Das INSTALL Kommando ist weiter eingerichtet, einen im Ladepaket umf assten Application Identifier, der sich auf die zu installierende Instanz des Applet bezieht, im Card Device einzurichten. Das Card Device ist dadurch gekennzeichnet, dass das INSTALL Kommando dazu eingerichtet ist, zum einen die Applet Instanz unter Berücksichtigung (zur Berücksichtigung werden nachfolgend zwei alternative Möglichkeiten dargelegt) des Application Identifiers zu installieren, und zum anderen mindestens einen weiteren Application Identif i- er, der sich auf dieselbe Instanz des Applet bezieht, im Card Device einzurichten. Hierdurch ist eine Möglichkeit geschaffen, mit einem INSTALL Kommando für ein bestimmtes Applet mehrere Identifier anzulegen, die sich alle auf dieselbe Applet Instanz beziehen. Ein Anlegen einer separaten Applet Instanz für jeden Application Identifier ist nicht erforderlich. Insbesonde- re ist es möglich, für unterschiedliche Konfigurationen eines Applet unterschiedliche Application Identifier bereitzustellen, mit nur einer einzigen zu Grunde liegenden im Card Device installierten Applet Instanz.
Folglich ist gemäß Anspruch 1 ein Card Device geschaffen, das eine spei- chersparende Installation von Applets im Card Device ermöglicht.
Gemäß einer ersten Möglichkeit (Alternative) zum Vorsehen mehrerer Application Identifier sind der Application Identifier und der mindestens eine weitere Application Identifier gleichzeitig im selben Ladepaket enthalten. Dabei ist das INSTALL Kommando so gestaltet, dass die Applet Instanz dahingehend unter Berücksichtigung des Application Identifiers installiert wird, dass mit der Abarbeitung eines einzigen INSTALL Kommandos nur eine einzige Applet Instanz im Card Device installiert wird, und zudem der Application Identifier und der mindestens eine weitere Application Identifier im Card Device eingerichtet werden.
Gemäß einer zweiten Möglichkeit (Alternative) zum Vorsehen mehrerer Ap- plication Identifier enthält das Ladepaket für den im Card Device anzulegenden Application Identifier und den mindestens einen weiteren im Card Device anzulegenden Application Identifier nur einen einzigen Application Identifier (AID1=AID2). Dabei wird die Applet Instanz dahingehend unter Berücksichtigung des Application Identifiers installiert, dass das INSTALL Kommando eingerichtet ist, den Application Identifier und den mindestens einen weiteren Application Identifier dadurch im Card Device einzurichten, dass das Ladepaket mindestens zweimal nacheinander in das Card Device geladen wird, wobei beim ersten Laden des Ladepakets eine Applet Instanz im Card Device eingerichtet wird und der Application Identifier eingerichtet wird, und bei jedem weiteren Laden des Ladepakets ein weiterer Application Identifier eingerichtet wird, ohne dass eine weitere Applet Instanz im Card Device angelegt wird. Hierbei erkennt also das Card Device, beim zweiten, dritten, ... INSTALL Kommando für eine Applet Instanz, dass bereits eine installierte Applet Instanz im Card Device vorhanden ist. Folglich wird keine weitere Applet Instanz im Card Device installiert sondern nur ein weiterer Application Identifier. Beim ersten INSTALL wird natürlich auch eine Applet Instanz angelegt.
Wahlweise ist im Ladepaket der Application Identifier - und bei der ersten Alternative ggf. der mindestens eine weitere Application Identifier - im INSTALL Kommando in den System Specific Parameters vorgesehen. Das Card Device ist wahlweise eingerichtet, den Application Identifier und den mindestens einen weiteren Application Identifier in einer Registry des Card Device abzuspeichern. Das Card Device ist beispielsweise eingerichtet als Chipkartenmodul oder als Chipkarte oder als Chipkartenmodul, das in ein Gehäuse anderer Bauform als einer Chipkarte implementiert ist.
Das Card Device umf asst weiter ein Betriebssystem, insbesondere ein Java Card Betriebssystem oder ein native Betriebssystem.
In einem erfindungsgemäßen Verfahren zum Anlegen eines Applet Identifi- ers in einem Card Device, zu einer im Card Device zu installierenden Instanz des Applet, mittels eines Ladepakets, sind gemäß einer ersten Möglichkeit (Alternative) die folgenden Schritte umfasst. 1) Laden des Ladepakets in das Card Device, wobei im Ladepaket ein Application Identifier umfasst ist, der sich auf die zu installierende Instanz des Applet bezieht. 2) Installieren einer Instanz des Applet in dem Card Device unter Anwenden eines INSTALL Kommandos auf das Ladepaket. 3) Auf Veranlassung des INSTALL Kom- mandos, Einrichten des Application Identifier im Card Device. Das Verfahren ist dadurch gekennzeichnet, dass im Ladepaket mindestens ein weiterer Application Identifier umfasst ist, der sich auf dieselbe zu installierende Instanz des Applet bezieht, und dass das Verfahren den weiteren Schritt umfasst: 4) Einrichten des mindestens einen weiteren Application Identifier im Card Device. Somit werden mit einem INSTALL Kommando eine Applet Instanz und zwei oder mehr Applet Identifier im Card Device angelegt.
In einem erfindungsgemäßen Verfahren zum Anlegen eines Applet Identif i- ers in einem Card Device, zu einer im Card Device zu installierenden Instanz des Applet, mittels eines Ladepakets, sind gemäß einer zweiten Möglichkeit (Alternative) die folgenden Schritte umfasst. 1) Laden des Ladepakets in das Card Device, wobei im Ladepaket ein Application Identifier umfasst ist, der sich auf die zu installierende Instanz des Applet bezieht. Vorzugsweise ent- hält das Ladepaket hierbei, wie üblich, pro Applet nur einen einzigen Applet Identifier. 2) Optional Installieren der Instanz des Applet in dem Card Device unter Anwenden eines INSTALL Kommandos auf das Ladepaket. 3) Auf Veranlassung des INSTALL Kommandos, Einrichten des Application Identifier im Card Device. Das Verfahren ist dadurch gekennzeichnet, dass 4) das Laden des Ladepakets mindestens zweimal nacheinander durchgeführt wird, wobei 5) beim ersten Laden des Ladepakets (bzw. beim ersten Ausführen des INSTALL Kommandos) das Installieren der Instanz des Applet durchgeführt wird (d.h. in Schritt 2) Option„Applet Installation") und der Application Identifier im Card Device eingerichtet wird, und 6) bei je- dem weiteren Laden des Ladepakets (bzw. Ausführen des INSTALL Kommandos) ein weiterer Application Identifier im Card Device eingerichtet wird, ohne dass eine weitere Instanz des Applet im Card Device eingerichtet wird (d.h. in Schritt 2 Option„keine Applet Instanz installieren"). Das Laden in Schritt 2) ist dahingehend optional, dass nur beim erstmaligen Laden des Ladepakets bzw. beim erstmaligen Anwenden des INSTALL Kommandos eine Applet Instanz im Device installiert wird, bei nachfolgenden weiteren Ladevorgängen bzw. INSTALL Kommando Ausführungen dagegen nicht.
Wahlweise umfasst das Card Device eine Registry, und das Einrichten des Application Identifier bzw. des weiteren Application Identifier umfasst das Speichern des Application Identifier bzw. des weiteren Application Identifier in der Registry, oder das Einrichten besteht im Abspeichern in der Registry. Gemäß Weiterbildungen der Erfindung ist dem Applet ein Parameter zugeordnet. Weiter sind dem Application Identifier und dem weiteren Application Identifier unterschiedliche Parameterwerte des Parameters des Applet zugeordnet. Durch den Parameter ist das Applet parametrisiert. Hierdurch ist für das Applet mittels des Parameters eine Konfiguration des Applet hergestellt. Unterschiedliche Parameterwerte des Parameters führen zu unterschiedlichen Konfigurationen des Applet. Somit werden mit einer einzigen Applet Instanz und mehreren Application Identifiern mehrere Konfigurationen des Applet verwirklicht, ohne dass mehrere Applet Instanzen im Card Device installiert sind.
Als Parameter und Parameterwerte sind wahlweise ein oder mehrere der folgenden vorgesehen: (1) als Parameter die Kontaktierungsart zum Kontaktieren des Card Device oder des Applet, und als unterschiedliche Parame- ter werte kontaktbehaftete und kontaktlose Kontaktierungsart; (2) als Parameter ein Land, in dem das Card Device oder das Applet genutzt wird, und als unterschiedliche Parameter werte unterschiedliche Länder.
Gemäß einer Ausführungsform der Erfindung sind dem Applet (mindestens oder genau) zwei Parameter zugeordnet, nämlich die Kontaktierungsart und das Land der Nutzung. Hierdurch lassen sich unterschiedliche Konfigurationen des Applet herstellen.
Wahlweise ist als Card Device ein SIM (beliebigen Formfaktors) für ein Mo- bilfunkgerät vorgesehen, wobei im SIM Applet mit anderer Funktionalität als SIM, z.B. Zahlungsverkehrsapplets, vorgesehen sind, wobei die erfindungsgemäßen Application Identifier AIDs sich auf die Applets anderer Funktionalität, z.B. Zahlungsverkehrsapplets, beziehen. Gemäß weiteren Ausführungsformen der Erfindung sind im Card Device Applet Instanzen für unterschiedliche Applets installiert. Wahlweise gibt es im Card Device einen (bzw. mindestens einen) eingerichteten Application Identifier, der Applet Instanzen von zwei unterschiedlichen Applets zuge- ordnet. Beispielsweise gibt es im Card Device eine Instanz von Applet A, eine Instanz von Applet B und einen AID, der sowohl auf die Instanz von Applet A als auch auf die Instanz von Applet B gerichtet ist.
Nachfolgendes Beispiel zeigt ein Card Device mit zwei Appletinstanzen zu zwei unterschiedlichen Applets, nämlich Applet A und Applet B, die mit zwei Parametern PI, P2 parametrisiert werden können.
Erster Parameter PI: Land; Parameter werte: Land X (Heimatland, z.B. Land eines Mobilfunkvertrags), Land Y, Land Z (andere Länder).
Zweiter Parameter P2: Kontaktierungsart; mögliche Parameterwerte: kon- taktbehaftet oder kontaktlos.
Applet A: virtuelle Kreditkarte Domestic.
Applet B: virtuelle Kreditkarte International.
Ziel: bestimmte Kombinationen Kn von erstem Parameter PI und zweiten Parameter P2 sollen gezielt bewirken, dass entweder Applet A oder Applet B genutzt wird.
Konkrete Beispiele für Ziele:
Kl: in Heimatland Land X soll im kontaktbehafteten Modus das für das Heimatland vorgesehene Applet A genutzt werden.
K2: In Ländern Y, Z soll immer das internationale Applet B genutzt werden. K3: Im Kontaktlos-Modus soll auch in Heimatland Land X das internationale Applet B genutzt werden.
Umsetzung: Applet A hat nur einen Application Identifier AID-A. Applet B hat zwei Application Identifier AID-INT-B und AID-DOM-NFC-B.
AID-A: Application Identifier Applet A. AID-I T-B: Application Identifier Applet B International.
AID-DOM-NFC-B: Application Identifier Applet B Domestic kontaktlos. Kl: Zugriff auf Card Device mit Parametern P1=X, P2=kontaktbehaftet und Application Identifier AID-A führt auf Applet A.
K2: Zugriff auf Card Device mit Parameter P1=Y oder Z, P2=kontaktbehaftet oder kontaktlos und Application Identifier AID-INT-B führt auf Applet B. K3: Zugriff auf Card Device mit Parametern Land P1=X, P2=kontaktlos und Application Identifier AID-DOM-NFC-B führt auf Applet B. Kurze Beschreibung der Zeichnungen
Im Folgenden wird die Erfindung an Hand von Ausführungsbeispielen und unter Bezugnahme auf die Zeichnung näher erläutert, in der zeigen:
Fig. 1 das Installieren einer Applet Instanz durch erstmaliges Senden eines Ladepakets, gemäß Ausführungsformen der Erfindung;
Fig. 2 das Personalisieren einer gemäß Fig. 1 installierten Applet Instanz, gemäß Ausführungsformen der Erfindung;
Fig. 3 das Aufrufen eines Applet mit AID1 und nachfolgende Abarbeitung von Kommandos, gemäß Ausführungsformen der Erfindung;
Fig. 4 das Anlegen eines weiteren Applet Identifier ohne Installieren einer weiteren Applet Instanz, gemäß Ausführungsformen der Erfindung; Fig. 5 das Personalisieren einer installierten Applet Instanz, gemäß Ausführungsformen der Erfindung;
Fig. 6 das Aufrufen eines Applet mit AID2 und nachfolgende Abarbeitung von Kommandos, gemäß Ausführungsformen der Erfindung.
Detaillierte Beschreibung von Ausführungsbeispielen
Fig. 1 zeigt das Installieren („INSTALL") einer Applet Instanz durch erstmaliges Senden eines Ladepakets, gemäß Ausführungsformen der Erfindung. Ein Terminal sendet an das Card Device (hier kurz als Card bezeichnet) APDU Kommandos. Mit dem Kommando ICC_ON schaltet das Terminal das Card Device ein. Mit APDU SELECT Card Manager wird der Card Manager aufgerufen. Mit APDU AUTHENTICATE wird eine Authentisierung durchgeführt. Mit dem APDU Kommando INSTALL FOR INSTALL wird ein Ladepaket in das Card Device geladen und eine Applet Instanz Applet Instance Object 1 im Card Device eingerichtet, indem dort mit„Create new" ein Applet Instance Object angelegt wird. Weiter wird der Applet Identifier AIDl des Applet, der in den System Specific Parameters des INSTALL mit- gesandt wird, im Card Device eingerichtet, indem in der Card Registry des Card Device mittels CREATE new ein neuer Card Registry Entry (Eintrag) eingetragen wird.
Fig. 2 zeigt das Personalisieren („Perso") einer gemäß Fig. 1 installierten Applet Instanz Applet Instance Object 1. Mit APDU SELECT und Angabe des AIDl wird die Applet Instanz ausgewählt. Mit APDU AUTHENTICATE wird eine Authentisierung durchgeführt. Mit mehreren aufeinanderfolgenden APDU STORE DATA, bis zu einem LAST STORE DATA, das das Ende der Personalisierungsdaten anzeigt, werden für die Personalisierung erfor- derliche Daten in das Card Device gespeichert. Hierdurch wird das Card
Device, genauer die installierte Applet Instanz Applet Instance Object 1, personalisiert („Perso").
Fig. 3 zeigt das Aufrufen („CALL") und Nutzen eines Applet mit AIDl und eine nachfolgende Abarbeitung von Kommandos, nach dem Installieren eines Applet nach Fig. 1 und Personalisieren des Applet nach Fig. 2. Mit APDU SELECT und Angabe des AIDl wird die Applet Instanz ausgewählt. Diverse Applet spezifische APDU Kommandos („Applet Specific Com- mands") werden nacheinander vom Terminal an das Card Device gesendet. Genauer wählt auf dem Card Device mittels SELECT der Card Manager die Applet Instanz APPLET Instance Object 1 aus und sendet vom Terminal empfangene APD US an das APPLET Instance Object. Hierdurch führt, auf dem Card Device, das Applet (genauer die Applet Instanz Applet Instance Object 1) seine (bzw. ihre) bestimmungsgemäße Tätigkeit aus.
Fig. 4 zeigt das Anlegen eines weiteren Applet Identifier mittels eines neuerlichen INSTALL FOR INSTALL-Kommandos, ohne dass eine weitere Applet Instanz im Card Device installiert wird, nach Ausführungsformen der Erfin- dung. Ein Terminal sendet an das Card Device (hier kurz als Card bezeichnet) APDU Kommandos. Mit dem Kommando ICC_ON schaltet das Terminal das Card Device ein. Mit APDU SELECT Card Manager wird der Card Manager aufgerufen. Mit APDU AUTHENTICATE wird eine Authentisie- rung durchgeführt. Mit dem APDU Kommando INSTALL FOR INSTALL wird ein Ladepaket in das Card Device geladen. Das Card Device stellt fest, dass bereits eine Applet Instanz Applet Instance Object 1 im Card Device eingerichtet ist und installiert keine weitere Applet Instanz. Weiter wird der Applet Identifier AIDl des Applet erkannt, der beim vorherigen INSTALL FOR INSTALL, beim Anlegen der Applet Instanz, der in den System Specific Parameters des INSTALL angelegt worden ist. Weiter wird, gemäß der Erfindung, im Card Device ein weiterer Applet Identifier AID2 eingerichtet, indem in der Card Registry des Card Device mittels CREATE new ein neuer Card Registry Entry (Eintrag) AID2 eingetragen wird. Nun enthält die Registry zu ein und derselben Applet Instanz Applet Instance Object 1 zwei Applet Identifier AIDl und AID2. Durch nochmaliges Senden des INSTALL FOR INSTALL Kommandos können noch weitere Applet Identifier AIDn, n = 3, 4, ... angelegt werden. Gemäß einer alternativen Vorgehensweise zum Anlegen von Applet Identifiern werden im INSTALL Kommando gleichzeitig mehrere Applet Identifier AIDl, AID2, ... vom Terminal an das Card De- vice zugesandt. Fig. 4 zeigt weiter ein Beispiel für das Anlegen der System Specific Parameters, um einen Applet Identif ier unterzubringen. Das
INSTALL for INSTALL Kommando umfasst ein Reihe von Ladeparametern, insbesondere Package AID, Applet Class AID, Instance AID, Privileges, Ap- plication Specific Parameters, System Specific Parameters und evtl. weitere, die allesamt in [1] aufgelistet sind. Die System Specific Parameters haben das Kommando Format EF Len TAG LEN VALUE (TLV Format). Für TAG sind manche Werte gemäß [1] fest vergeben, beispielsweise C6, C7 und C8 (vgl.
[1], Kap. 11.5.2.3.7„INSTALL Command Parameters"). Vorzugsweise wird für TAG ein Wert verwendet, der nicht fest vergeben ist, beispielsweise 4F.
Fig. 5 zeigt das Personalisieren („Perso") einer installierten Applet Instanz, nach Ausführungsformen der Erfindung. Mit APDU SELECT und Angabe eines der mehreren AIDs, hier des AID2, wird die Applet Instanz ausge- wählt, hier Applet Instance Object 1 (nicht 2!). Mit APDU AUTHENTICATE wird eine Authentisierung durchgeführt. Mit mehreren aufeinanderfolgenden APDU STORE DATA, bis zu einem LAST STORE DATA, das das Ende der Personalisierungsdaten anzeigt, werden für die Personalisierung erforderliche Daten in das Card Device gespeichert. Hierdurch wird das Card Device personalisiert („Perso").
Fig. 6 zeigt das Aufrufen („CALL") und Nutzen eines Applet mit einem weiteren Applet Identifier AID2 und eine nachfolgende Abarbeitung von Kommandos, nach einer Ausführungsform der Erfindung. Mit APDU SELECT und Angabe des weiteren Applet Identifier AID2 wird die Applet Instanz ausgewählt. Diverse Applet spezifische APDU Kommandos („Applet Specific Commands") werden nacheinander vom Terminal an das Card Device gesendet. Genauer wählt auf dem Card Device mittels SELECT der Card Manager das APPLET Instance Object 1 (nicht 2) aus und sendet vom Termi- nal empfangene APD US an das APPLET Instance Object 1. Hierdurch führt, auf dem Card Device, das Applet (genauer die Applet Instanz 1) seine (bzw. ihre) bestimmungsgemäße Tätigkeit aus, initiiert mit dem weiteren Applet Identifier AID2, und bezogen auf ein und dieselbe Applet-Instanz 1.
Zitierter Stand der Technik
[1] [GPC_SPE_034] Global Card Platform Specification V2.2.1, 2011

Claims

P a t e n t a n s p r ü c h e
1. Card Device, eingerichtet ein Ladepaket für ein Applet entgegenzunehmen und ein INSTALL Kommandos abzuarbeiten und auf das Ladepaket anzuwenden, um ein Installieren einer Instanz (Applet Instance Object 1) des Applet im Card Device zu veranlassen, wobei das INSTALL Kommando eingerichtet ist, einen im Ladepaket umfassten Application Identifier (AID1), der sich auf die zu installierende Instanz des Applet (Applet Instance Object 1) bezieht, im Card Device einzurichten,
dadurch gekennzeichnet, dass
das INSTALL Kommando eingerichtet ist:
- die Applet Instanz (Applet Instance Object 1) unter Berücksichtigung des Application Identifier (AID1; AID2) zu installieren; und
- mindestens einen weiteren Application Identifier (AID2), der sich auf die- selbe Instanz (Applet Instance Object 1) des Applet bezieht, im Card Device einzurichten.
2. Card Device nach Anspruch 1, wobei der Application Identifier (AID1) und der mindestens eine weitere Application Identifier (AID2) gleichzeitig im selben Ladepaket enthalten sind, und wobei die Applet Instanz (Applet Instance Object 1) dahingehend unter Berücksichtigung des Application Identifiers (AID1; AID2) installiert wird, dass mit der Abarbeitung eines einzigen INSTALL Kommandos nur eine einzige Applet Instanz (Applet Instance Object 1) im Card Device installiert wird, und der Application Identi- fier (AID1) und der mindestens eine weitere Application Identifier (AID2) im Card Device eingerichtet werden.
3. Card Device nach Anspruch 1, wobei das Ladepaket für den Application Identifier (AID1) und den mindestens einen weiteren Application Identifier (AID2) nur einen einzigen Application Identifier (AID1=AID2) enthält, und wobei die Applet Instanz dahingehend unter Berücksichtigung des Applica- tion Identifiers installiert wird, dass das INSTALL Kommando eingerichtet ist, den Application Identifier (AID1) und den mindestens einen weiteren Application Identifier (AID2) dadurch im Card Device einzurichten, dass das Ladepaket mindestens zweimal nacheinander in das Card Device geladen wird, wobei beim ersten Laden des Ladepakets eine Applet Instanz (Applet Instance Object 1) im Card Device eingerichtet wird und der Application Identifier (AID1) eingerichtet wird und bei jedem weiteren Laden des Ladepakets einer des mindestens einen weiteren Application Identifier (AID2, AID3, ...) eingerichtet wird, ohne dass eine weitere Applet Instanz in Card Device angelegt wird.
4. Card Device nach einem der Ansprüche 1 bis 3, wobei im Ladepaket der Application Identifier (AID1) und ggf. der mindestens eine weitere Application Identifier (AID2, AID3, ...) im INSTALL Kommando in den System Spe- cific Parameters vorgesehen ist.
5. Card Device nach einem der Ansprüche 1 bis 4, eingerichtet, den Application Identifier (AID1) und den mindestens einen weiteren Application Identifier (AID2, AID3, ...) in einer Registry des Card Device abzuspeichern.
6. Card Device nach einem der Ansprüche 1 bis 5, eingerichtet als Chipkartenmodul oder als Chipkarte oder als Chipkartenmodul, das in ein Gehäuse anderer Bauform als einer Chipkarte implementiert ist.
7. Card Device nach einem der Ansprüche 1 bis 6, weiter umfassend ein Betriebssystem, insbesondere ein Java Card Betriebssystem oder ein native Betriebssystem.
8. Verfahren zum Anlegen eines Applet Identifiers in einem Card Device, zu einer im Card Device zu installierenden Instanz (Applet Instance Object 1) des Applet, mittels eines Ladepakets, umfassend die Schritte:
- Laden des Ladepakets in das Card Device, wobei im Ladepaket ein Appli- cation Identifier (AIDl) umfasst ist, der sich auf die zu installierende Instanz
(Applet Instance Object 1) des Applet bezieht;
- Installieren einer Instanz (Applet Instance Object 1) des Applet in dem Card Device unter Anwenden eines INSTALL Kommandos auf das Ladepaket;
- auf Veranlassung des INSTALL Kommandos, Einrichten des Application Identifier (AIDl) im Card Device; dadurch gekennzeichnet, dass
im Ladepaket mindestens ein weiterer Application Identifier (AID2) umfasst ist, der sich auf dieselbe zu installierende Instanz (Applet Instance Object 1) des Applet bezieht,
und dass das Verfahren den weiteren Schritt umfasst:
- Einrichten des mindestens einen weiteren Application Identifier (AID2, AID3, ... ) im Card Device.
9. Verfahren zum Anlegen eines Applet Identifiers in einem Card Device, zu einer im Card Device zu installierenden Instanz (Applet Instance Object 1) des Applet, mittels eines Ladepakets, umfassend die Schritte:
- Laden des Ladepakets in das Card Device, wobei im Ladepaket ein Application Identifier (AIDl) umfasst ist, der sich auf die zu installierende Instanz (Applet Instance Object 1) des Applet bezieht;
- optional Installieren der Instanz (Applet Instance Object 1) des Applet in dem Card Device unter Anwenden eines INSTALL Kommandos auf das Ladepaket;
- auf Veranlassung des INSTALL Kommandos, Einrichten des Application Identifier (AIDl) im Card Device; dadurch gekennzeichnet, dass das Laden des Ladepakets mindestens zweimal nacheinander durchgeführt wird, wobei beim ersten Laden des Ladepakets das Installieren der Instanz (Applet Instance Object 1) des Applet durchgeführt wird und der Application Identifier (AID1) im Card Device eingerichtet wird, und wobei bei jedem weiteren Laden des Ladepakets ein weiterer Application Identifier ( AID2, AID3, ...) im Card Device eingerichtet wird, ohne dass eine weitere Instanz des Applet im Card Device eingerichtet wird.
10. Verfahren nach Anspruch 8 oder 9, wobei das Card Device eine Registry umfasst, und wobei das Einrichten des Application Identifier (AID1) bzw. des weiteren Application Identifier (AID2, AID3, ...) das Speichern des Application Identifier (AID1) bzw. des weiteren Application Identifier (AID2, AID3, ...) in der Registry umfasst oder in dem Abspeichern in der Registry besteht.
11. Card Device nach einem der Ansprüche 1 bis 7, oder Verfahren nach einem der Ansprüche 8 bis 10, wobei dem Applet mindestens ein Parameter (PI, P2, ...) zugeordnet ist, und wobei dem Application Identifier (AID1) und dem weiteren Application Identifier (AID2, AID3, ...) unterschiedliche Parameterwerte des Parameters zugeordnet sind.
12. Card Device oder Verfahren nach Anspruch 11, wobei als Parameter und Parameterwerte ein oder mehrere der folgenden vorgesehen sind:
(1) Parameter (PI) Land, in dem das Card Device oder das Applet genutzt wird, mit unterschiedlichen Parameterwerten unterschiedliche Länder;
(2) Parameter (P2) Kontaktierungsart des Card Device oder des Applet, mit unterschiedlichen Parameterwerten kontaktbehaftet und kontaktlos.
13. Card Device oder Verfahren nach Anspruch 11 oder 12, wobei im Card Device Applet Instanzen für unterschiedliche Applets installiert sind, und wobei mindestens ein im Card Device eingerichteter Application Identif ier Applet Instanzen von zwei unterschiedlichen Applets zugeordnet ist.
EP17732302.9A 2016-06-14 2017-06-09 Ressourcenbeschränktes java card device Ceased EP3469479A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102016007189.3A DE102016007189A1 (de) 2016-06-14 2016-06-14 Ressourcenbeschränktes Java Card Device
PCT/EP2017/000679 WO2017215782A1 (de) 2016-06-14 2017-06-09 Ressourcenbeschränktes java card device

Publications (1)

Publication Number Publication Date
EP3469479A1 true EP3469479A1 (de) 2019-04-17

Family

ID=59152812

Family Applications (1)

Application Number Title Priority Date Filing Date
EP17732302.9A Ceased EP3469479A1 (de) 2016-06-14 2017-06-09 Ressourcenbeschränktes java card device

Country Status (5)

Country Link
US (1) US10735559B2 (de)
EP (1) EP3469479A1 (de)
CN (1) CN109313545B (de)
DE (1) DE102016007189A1 (de)
WO (1) WO2017215782A1 (de)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102016007189A1 (de) * 2016-06-14 2017-12-14 Giesecke+Devrient Mobile Security Gmbh Ressourcenbeschränktes Java Card Device
DE102017002151A1 (de) 2017-03-06 2018-09-06 Giesecke+Devrient Mobile Security Gmbh Card Device mit Applets und Weitergabe von APDUs an Applets
DE102017002153A1 (de) 2017-03-06 2018-09-06 Giesecke+Devrient Mobile Security Gmbh Übergang von einer booleschen Maskierung zu einer arithmetischen Maskierung
CN110865855B (zh) * 2019-11-18 2023-10-27 百度在线网络技术（北京）有限公司 小程序处理方法及相关设备
EP3926504B1 (de) 2020-06-19 2024-08-21 Giesecke+Devrient ePayments GmbH Ein- und ausblenden von java-karten-applet-instanzen
CN112712356B (zh) * 2020-12-30 2022-04-15 深圳杰睿联科技有限公司 一种配置Java Card参数的方法和系统

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6907608B1 (en) * 1999-01-22 2005-06-14 Sun Microsystems, Inc. Techniques for permitting access across a context barrier in a small footprint device using global data structures
US8196131B1 (en) * 2010-12-17 2012-06-05 Google Inc. Payment application lifecycle management in a contactless smart card
FR2997205B1 (fr) * 2012-10-23 2014-10-31 Morpho Procede de gestion d'identifiants dans une carte a circuit integre et carte a circuit integre correspondante
US20150127529A1 (en) * 2013-11-05 2015-05-07 Oleg Makhotin Methods and systems for mobile payment application selection and management using an application linker
BR112016014106A2 (pt) * 2013-12-19 2017-08-08 Visa Int Service Ass Método para intensificar a segurança de um dispositivo de comunicação, e, dispositivo de comunicação
CN103729179B (zh) * 2013-12-25 2017-02-15 飞天诚信科技股份有限公司 安全执行委托管理命令的方法
US9483249B2 (en) * 2014-01-06 2016-11-01 Apple Inc. On-board applet migration
CN105320686A (zh) * 2014-07-29 2016-02-10 苏州融卡智能科技有限公司 一种优化java卡选择实例的方法
US9775029B2 (en) * 2014-08-22 2017-09-26 Visa International Service Association Embedding cloud-based functionalities in a communication device
DE102016007189A1 (de) * 2016-06-14 2017-12-14 Giesecke+Devrient Mobile Security Gmbh Ressourcenbeschränktes Java Card Device

Also Published As

Publication number Publication date
CN109313545A (zh) 2019-02-05
US10735559B2 (en) 2020-08-04
DE102016007189A1 (de) 2017-12-14
US20190335017A1 (en) 2019-10-31
WO2017215782A1 (de) 2017-12-21
CN109313545B (zh) 2022-08-02

Similar Documents

Publication Publication Date Title
WO2017215782A1 (de) Ressourcenbeschränktes java card device
EP2898714B1 (de) Identitätsmodul zum authentisieren eines teilnehmers in einem kommunikationsnetzwerk
WO2010009789A1 (de) Laden und aktualisieren einer personalisierungsbedürftigen applikation
WO2016128137A1 (de) Verfahren zum betreiben eines sicherheitselements
EP2987350A1 (de) Mobilstation umfassend sicherheitsressourcen mit unterschiedlichen sicherheitsniveaus
DE102012015573A1 (de) Verfahren zum Aktivieren eines Betriebssystems in einem Sicherheitsmodul
WO2018162117A1 (de) Card device mit applets und weitergabe von apdus an applets
EP1230780A1 (de) Anpassbare chipkarte
DE102013013178A1 (de) Verfahren und Vorrichtungen zum Wechseln eines Mobilfunknetzes
EP3452946B1 (de) Verfahren zur erstmaligen inbetriebnahme eines nicht vollständig personalisierten sicheren elements
DE19751318A1 (de) Softwaregesteuertes Teilnehmerendgerät, Server zum Bereitstellen eines Steuerprogrammes und Verfahren zum Betrieb des softwaregesteuerten Teilnehmerendgerätes
EP3159821B1 (de) Prozessor-system mit applet security settings
DE102019000743A1 (de) Verfahren und Vorrichtungen zum Verwalten von Subskriptionsprofilen eines Sicherheitselements
WO2011033030A1 (de) Verfahren zum installieren und konfigurieren von applikationen auf einem portablen datenträger
EP1610218B1 (de) Tragbarer Datenträger, System mit einem solchen Datenträger und Verfahren zum Betreiben eines solchen Datenträgers
DE102010018021A1 (de) Verfahren zum Konfigurieren einer Applikation für ein Endgerät
EP3488375B1 (de) Chipset mit gesicherter firmware
DE10324995A1 (de) Verfahren zum Laden von tragbaren Datenträgern mit Daten
DE19928468C2 (de) Verfahren zum Einschreiben von Daten in den programmierbaren Festwertspeicher (EEPROM) eines mikroprozessorgestützten, tragbaren Datenträgers
DE10226344B4 (de) Verfahren und Anordnung zum Zugreifen auf Rufnummernportabilitätsdaten
EP4409946A1 (de) Universal integrated chip card, uicc, zum verwalten von profilen, sowie verfahren
DE102024120757A1 (de) Verfahren zum Einrichten eines Benutzergerätes, Einrichtungsprogramm, computerlesbarer Datenträger, Benutzergerät und Einrichtungsanordnung dafür
DE102018007595A1 (de) Teilnehmeridentitätsmodul mit Profilen und Applikationen
DE102015210551A1 (de) Verfahren für eine verbesserte Installation einer auf ein sicheres Element bezogenen Dienstanwendung in einem sicheren Element, das sich in einer Kommunikationsvorrichtung befindet, System und Telekommunikationsnetz für eine verbesserte Installation einer auf ein sicheres Element bezogenen Dienstanwendung in einem sicheren Element, das sich in einer Kommunikationsvorrichtung befindet, Programm, das einen maschinenlesbaren Programmcode umfasst, und Computerprogrammprodukt
DE102018006375A1 (de) Selektives Betriebssystem-Laden in ein Teilnehmeridentitätsmodul

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

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

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

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

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

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20190114

AK Designated contracting states

Kind code of ref document: A1

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

AX Request for extension of the european patent

Extension state: BA ME

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20191121

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: 20221018